Amiga Plus 1995 #2/Amiga Plus CD - 1995 - No. 2.iso/internet/faq/englisch/medicalimageformat

Text File | 1995-04-11 | 189.0 KB | 4,572 lines

Archive-name: medical-image-faq/part1
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01

This message is automatically posted once a month to help readers looking
for information about medical image formats. If you don't want to see this
posting every month, please add the subject line to your kill file.

Contents:

    part1    - contains index, general information & standard formats
    part2    - contains standard formats (continued)
    part3    - contains information about proprietary CT formats
    part4    - contains information about proprietary MR formats
    part5    - contains information about proprietary other formats
    part6    - contains information about hosts & compression
    part7    - contains information sources
    part8    - contains information sources (continued)

Tools that describe and convert many of the formats described in this document
are available in the dicom3tools package from

    "ftp://ftp.rahul.net/pub/dclunie/".

A Mosaic browsable version of this FAQ is available at:

    "http://www.rahul.net/dclunie/medical-image-faq/html/".

Html, postscript and text forms of the FAQ are available at:

    "ftp://ftp.rahul.net/pub/dclunie/medical-image-faq/".

Many FAQs, including this Listing, are available on the archive site
rtfm.mit.edu in the directory pub/usenet/news.answers.  The name under
which a FAQ is archived appears in the Archive-name line at the top of
the article.

There's a mail server on that machine. You send a e-mail message to
[e-mail] containing the keyword "help" (without quotes!)
in the message body. To fetch this particular FAQ send a message with the
following body:

    send usenet/news.answers/medical-image-faq/part1
    ...
    send usenet/news.answers/medical-image-faq/part8

Please direct comments or questions and especially contributions to

    "[e-mail]"

or reply to this article. All unknown formats and test images gratefully
accepted, but please don't email them, rather contact me and we can
arrange to exchange documents or disks or tapes by snail mail.


Changes this issue

    Split into 8 smaller parts for News software that baulks on big posts.
    Fixed numerous typos and difficulties with converting html to posting.
    Visible Human project information.
    RSNA WWW server.
    New Evergreen Technologies email address.
    More Mac and Windows viewer sources.
    Dermatology server.
    Physics server.
    Fully functional 3DVIEWNIX1.1 now available for ftp.
    Teleradiology vendors.
    An NIH image macro to import ACR/NEMA files.
    A few more Genesis hints/updates.
    Update SCAR email address.
    Ftp site for Linux DICOM CTN software.
    Updated HSPNET-L entry.
    Updated ADAM entry.
    Angiography simulation site.
    GE Ultrasound contact.
    sci.med.radiology gateway.
    Neuroscience Resources List www site.
    Radiology history www site.
    Updated DeJarnette details.
    Updated Papyrus entry.
    PET www site.
    EurIPACS www site.
    ImportAccess Photoshop plugin.
    Described SPI in much more detail.
    Siemens SPI devices including Somatom Plus, Impact, SP.
    Sytec format added.
    Siemens DR CT format updated.
    ISG/Philips Gyroview comments added.

Changes last issue

    Update to World Wide Web HTML format.
    Sytec format is different from PACE.
    Genesis architecture is Sun3 68000 not Sun4 SPARC.
    Add Genesis DAT format.
    Add newsgroups entry to sources.
    Rearranged the resources stuff a little.
    Incorporated some DICOM resources from Dwight Simon's directory.
    Added DICOM references made available at RSNA 1994.
    GE ftp site for conformance statements and sample DICOM images.
    Remove some of the gratuitous anti-VMS nasty comments.
    Change DICOM File Meta Information Header Transfer Syntax to Explicit VR.


Subject: Contents

1.  Introduction

    1.1 Objective
    1.2 Types of Formats
    1.3 In Desperation - Quick & Dirty Tricks

2.  Standard Formats

    2.1 ACR/NEMA 1.0 and 2.0
    2.2 ACR/NEMA DICOM 3.0
    2.3 Papyrus
    2.4 Interfile V3.3
    2.5 Qsh

3.  Proprietary Formats

    3.1 General

        3.1.1 SPI (Standard Product Interconnect)

    3.2 CT

        3.2.1 General Electric

              3.2.1.1 CT 9800

                      3.2.1.1.1 Image data
                      3.2.1.1.2 Tape format
                      3.2.1.1.3 Raw data

              3.2.1.2 CT Advantage - Genesis

                      3.2.1.2.1 Image data
                      3.2.1.2.2 Archive format
                      3.2.1.2.3 Raw data

              3.2.1.3 Pace
              3.2.1.4 Sytec

        3.2.2 Siemens

              3.2.2.1 Somatom DR
              3.2.2.2 Somatom Plus
              3.2.2.3 Somatom AR

        3.2.3 Philips
        3.2.4 Picker
        3.2.5 Toshiba
        3.2.6 Hitachi
        3.2.7 Shimadzu
        3.2.8 Elscint

    3.3 MR

        3.3.1 General Electric

              3.3.1.1 Signa 3X and 4X

                      3.3.1.1.1 Image data
                      3.3.1.1.2 Tape format
                      3.3.1.1.3 Raw data

              3.3.1.2 Signa 5X - Genesis

                      3.3.1.2.1 Image data
                      3.3.1.2.2 Archive format
                      3.3.1.2.3 Raw data

              3.3.1.3 Vectra

        3.3.2 Siemens

              3.3.2.1 GBS II
              3.3.2.2 SP
              3.3.2.3 Impact
              3.3.2.4 Vision

        3.3.3 Philips

              3.3.3.1 S5
              3.3.3.2 ACS
              3.3.3.3 T5
              3.3.3.4 NT5 & NT15

        3.3.4 Picker
        3.3.5 Toshiba
        3.3.6 Hitachi
        3.3.7 Shimadzu
        3.3.8 Elscint

    3.4 Proprietary Workstations

        3.4.1 ISG Workstations

              3.3.3.1 Gyroview

    3.5 Other

4.  Host Machines

    4.1 Data General

        4.1.1 Data

              4.1.1.1 Integers
              4.1.1.2 Floating Point

        4.1.2 Operating System

              4.1.2.1 RDOS
              4.1.2.2 AOS/VS

        4.1.3 Network

    4.2 Vax

        4.2.1 Data

              4.2.1.1 Integers
              4.2.1.2 Floating Point
              4.2.1.3 Strings

        4.2.2 Operating System

              4.2.2.1 VMS
              4.2.2.2 ULTRIX
              4.2.2.3 OSF

    4.3 Sun - Sun3 68000 and Sun4 Sparc

        4.3.1 Data

              4.3.1.1 Integers
              4.3.1.2 Floating Point
              4.3.1.3 Strings

        4.3.2 Operating System

5.  Compression Schemes

    5.1 Reversible
    5.2 Irreversible

        5.2.1 Perimeter Encoding

6.  Getting Connected

    6.1 Tapes
    6.2 Ethernet
    6.3 Serial Ports

7.  Sources of Information

    7.1 Vendor Contacts
    7.2 Relevant FAQ's
    7.3 Source Code
    7.4 Commercial Offerings
    7.5 FTP/WWW sites
    7.6 Mailservers
    7.7 References
    7.8 Organizations and Societies
    7.9 Usenet Newsgroups

8.  Acknowledgements


1.  Introduction

    1.1 Objective

        The goal of this FAQ is to facilitate access to medical images stored
on digital imaging modalities such as CT and MR scanners, and their
accompanying descriptive information. The document is designed particularly for
those who do not have access to the necessary proprietary tools or
descriptions, particularly in those moments when inspiration strikes and one
just can't wait for the local sales person to track down the necessary
authority and go through the cycle of correspondence necessary to get a
non-disclosure agreement in place, by which time interest in the project has
usually faded, and another great research opportunity has passed! It may also
be helpful for those keen to experiment with home-grown PACS-like systems using
their existing equipment, and also for those who still have equipment that is
still useful but so old even the host computer vendor doesn't support it any
more!

        There is of course no substitute for the genuine tools or descriptions
from the equipment vendors themselves, and pointers to helpful individuals in
various organizations, as well as names and catalog numbers of various useful
documents, are included here where known.

        In addition there are several small companies that specialize in such
connectivity problems that have a good reputation and are well known. Contact
information is provided for them, though I personally have no experience with
their products and am not endorsing them.

        Finally, great care has been taken not to include any information that
has been released under non-disclosure agreements. What is included here is the
result of either information freely released by vendors, handy hints from
others working in the field, or in many cases close scrutiny of hex dumps and
experimentation with scanner parameters and study of the effects on the image
files. The intent is to spread hard-earned knowledge gained over many years
amongst those new to the field or a particular piece of equipment, not to
threaten anyone's proprietary interests, or to substitute for the technical
support available from vendors that ranges from free to extortionate, and
excellent to abysmal, depending on who your are dealing with and where in the
world you are located!

         Please use this information in the spirit in which is intended, and
where possible contribute whatever you know in order to expand the information
to cover more vendors and equipment.

    1.2 Types of Formats

        Later sections will deal with the problems of getting the image files
from the modality to the workstation, but for the moment assume the files are
there and need to be deciphered.

        Four types of information are generally present in these files:

           - image data, which may be unmodified or compressed,
           - patient identification and demographics,
           - technique information about the exam, series, and slice/image.

        Extracting the image information alone is usually straightforward and
is described in 1.3. Dealing with the descriptive information, for example to
make use of the data for dissemination in a PACS environment, or to extract
geometry details in order to combine images into 3D datasets, is more difficult
and requires deeper understanding of how the files are constructed.

        There are three basis families of formats that are in popular use:

           - fixed format, where layout is identical in each file,
           - block format, where the header contains pointers to information,
           - tag based format, where each item contains its own length.

        The block format is one of the most popular, though in most cases, the
early part of the header contains only a limited number of pointers to large
blocks, the blocks are almost always in the same place and a constant length,
for standard rather than reformatted images at least, and if one doesn't know
the specifics of the layout one can get by assumming a fixed format. I presume
this reflects the intent of the designers to handle future expansion and
revision of the format.

         The example par excellence of the tag based format is the ACR/NEMA
style of data stream, which, though never intended as a file format per se has
proven useful as model. See for example the sections dealing with the ACR/NEMA
standards as well as DICOM (whose creators are about to vote on a media
interchange format after all this time) and Papyrus. ACR/NEMA style tags are
described in more detail elsewhere, but each is self-contained and
self-describing (at least if you have the appropriate data dictionary) and
contains its own length, so if you can't interpret it you can skip it! Very
convenient. Most file formats based on this scheme are just concatenated series
of tags, and apart from having to guess the byte order, which is not specified
(unlike TIFF which is a similar deal for those in the "real" imaging world),
and sometimes skip a fixed length but short header, are dead easy to handle.

         To identify such a file just do a "strings <file | grep 'ACR-NEMA'" -
if it is such a file, just look through the start of the hex dump until you
start to see the characteristic sequentially ordered pairs of 16 bit words that
identify ACR/NEMA attributes, decide the byte order, et voila, you can pipe it
into any general ACR/NEMA dumping program to see what it contains. If you see
even group tags, they will be described in the standard. If you see odd group
tags then they are vendor specific and you will have to ask the vendor or
correlate them with identification information printed on the film until you
figure out the ones that are important to you.

    1.3 In Desperation - Quick & Dirty Tricks

        Because radiologists, radiographers, technologists, physicists and
imaging programmers are dedicated long suffering creatures who work long hours
under adverse conditions for little reward, the vendors in their generosity
have seen fit to make life a little easier, by almost universally putting the
image data at the end of the file. Rarely you will see files that are padded
out to fixed record size boundaries (eg. Vax VMS 512 byte records), and
sometimes overlay plane data may be stored after the image data. Furthermore
there is almost always an option at archive time to allow for storage in an
uncompressed and totally unadulterated form. Even in ACR/NEMA the tag for image
pixel data is numerically the highest and hence the last to appear in the
sequence which is guaranteed to be sorted. They could have screwed us up
totally by gratuitously adding variable length blocks of other stuff at the
end, but the only time I have encountered this was on a Siemens Impact with the
ACR/NEMA based SPI format padded out to 512 bytes.

        In other words, if an image is 256 by 256, uncompressed, and 12-16 bits
deep (and hence usually, though not always, stored as two bytes per pixel),
then we all know that the file is going to contain 256*256*2=131072 bytes of
pixel data at the end of the file. If the file is say 145408 bytes long, as all
GE Signa 3X/4X files are for example, then you need to skip 14336 bytes of
header before you get to the data. Presume row by row starting with top left
hand corner raster order, try both alternatives for byte order, deal with the
16 to 8 bit windowing problem, and very soon you have your image on the screen
of your workstation.

         This technique is so useful, even NIH Image for the Macintosh (an
excellent must-have free program BTW.) provides a raw import tool to do this,
and describes it in the manual using the 14336 byte offset! This tool is
something that is sadly lacking in most commercial image handling programs for
non-medical applications, which can't import images with more than 8 bits per
channel.

         Of course you have to live without the identification, demographic and
technique information (other than what can be derived from the file name in
some cases), but for many research and presentation purposes this is quite
adequate.

         Occasionally one runs into clever files where four 12 bit words are
packed into three 16 bit words and one goes crazy trying to figure out the
logic of how they are packed. The back of the old ACR/NEMA standard describes
somewhere one way in which this is done. One should still be able to calculate
the length easily enough.

         I haven't yet encountered a format that did nasty things like have
strips of rows seperated by padding ... I guess we are lucky that most images
are nice powers of two or even multiples thereof (256,320,512).

         Of course the GE CT 9800 uses perimeter encoding even when DPCM
compression is not selected, so this technique won't work.

2.  Standard Formats

    2.1 ACR/NEMA 1.0 and 2.0

        ACR/NEMA Standards Publication No. 300-1985      <- ACR/NEMA 1.0
        ACR/NEMA Standards Publication No. 300-1988      <- ACR/NEMA 2.0
        ACR/NEMA Standards Publication PS2-1989          <- data compression

        The American College of Radiologists (ACR) and the National Electrical
Manufacturers Association (NEMA) recognized some time ago the need for
standards to facilitate multi-vendor connectivity to promote the development of
PACS and what is now referred to as Wide Area Networking. The first such
standard was version 1.0 which was released in 1985 as ACR/NEMA Standards
Publication No. 300-1985, subsequently revised several times, then revised
again and released as version 2.0 in 1988, described in ACR/NEMA Standards
Publication No. 300-1988. There it remained until a radically revised and
reorganized approach, preserving backward compatibility, was released during
1992-1993 as ACR/NEMA Standards Publication PS3, also referred to as DICOM 3.

        In the interim, to facilitate the transfer of compressed images,
another standard described in ACR/NEMA Standards Publication PS2-1989, was
released which described various means fo extending standard 300-1985 to handle
compression utilizing a broad range of reversible and irreversible schemes.
Though this part of the standard was never apparently implemented by anyone,
and has been quietly bypassed by those working on DICOM 3 compression, it makes
very interesting reading and is a nice summary of applicable techniques.

        What does one need to know about ACR/NEMA 1.0 and 2.0 ? The standards
define a mechanism along the lines of the layered ISO-OSI (Open Systems
Interconnect) model, with physical, transport/network, session, and
presentation and application layers. Unless one actually wants to physically
connect to a device that supports the unique 50 pin point-to-point electrical
interface, then one really only needs to be aware of how ACR/NEMA implements
the presentation and application layers, which are described in terms of a
"message format". This message format is important to many people, not because
anyone seriously wants to connect devices in the limited fashion envisaged by
these early standards, but because many proprietary formats and other de facto
standards have adopted the ACR/NEMA message format and its corresponding data
dictionary and extension mechanisms.

         The message format is described in sections 4, 5 and 10 of ACR/NEMA SP
300-1988 which are summarized briefly here. Section 6 describes command
structure which is not really relevant other than that commands are also
structured in the same way as data and consume part of the data dictionary. You
will not encounter command tags in data streams ("messages") encapsulated in
file formats though.

         A message consists of a series of "data elements" each of which
contains a piece of information. Each element is described by an "element name"
consisting of a pair of 16 bit unsigned integers ("group number", "data element
number"). The data stream is ordered by ascending group number, and within each
group by ascending data element number. Each element may occur only once in a
message. Even numbered groups describe elements defined by the standard. Odd
numbered groups are available for use by vendors or users, but must conform to
the same structure as standard elements. Following the (group number, data
element number) pair is a length field that is a 32 bit unsigned even integer
that describes the number of bytes from the end of the length field to the
beginning of the next data element. The last part of a data element is its
value, which is defined by the data dictionary to be an ascii (numeric AN or
text AT) or binary value (BI 16 bit or BD 32 bit), which may be single values
or multiple in which case ascii values are delimited by the '\' backslash
character. Odd length ascii values are padded with a space (020H).

        For example:

            0008 0010  000C 0000  4341 2D52 454E 414D
                                  3120 302E

        is data element "Recognition Code" because that is what the dictionary
defines group 0008 element 0010 to be. The dictionary says it is of type AT
(ascii text), has a value multiplicity of single and only enumerated values are
allowed, in this case the ascii string "ACR-NEMA 2.0". It is of length 0000000C
hex or 12 bytes long.

        Note that the electrical interface is a 16 bit one, and hence even
though 32 binary values are defined to be transmitted least significant word
first (though the order for the 32 bit length is not actually specified), there
is no mention in the standard as to how to encapsulate the message in an 8 bit
world, hence different users and vendors have chosen little or big endian
schemes. The new DICOM standard assumes a default little endian representation
which seems to be the most appropriate considering the old definition for 32
bit words.

        Notice particularly how this design allows one to parse the message
even if the data dictionary is not complete. Consider an element that has an
unrecognized element name. One cannot interpret the content of the element and
so has to ignore it. One doesn't even know whether it contains binary or ascii
information (this is what DICOM later refers to as "implicit representation".
despite this, the length value allows one to skip to the next element and
proceed.

        Over the years there has been much discussion amongst those who favour
such implicit dictionary driven schemes, and those who prefer explicit
representations, including explicit description of the element type (binary or
ascii, etc.) and even the element description itself! Some would prefer the
message to contain something like "RecognitionCode='ACR-NEMA 2.0';" for
example. The nuclear medicine groups have adopted a de facto standard called
Interfile that makes use of ACR/NEMA data elements, but uses such a descriptive
representation. Their argument is that the data stream is much more readable
which is true enough, and more readily extensible.

        The groups are organized as follows:

            0000                    Command
            0008                    Identifying
            0010                    Patient
            0018                    Acquisition
            0020                    Relationship
            0028                    Image Presentation
            4000                    Text
            6000-601E (even)        Overlay
            7FE0                    Pixel Data

        Some of the more interesting elements are:

            (nnnn,0000) BD S Group Length           # of bytes in group nnnn
            (nnnn,4000) AT M Comments

            (0008,0010) AT S Recognition Code       # ACR-NEMA 1.0 or 2.0
            (0008,0020) AT S Study Date             # yyyy.mm.dd
            (0008,0020) AT S Series Date            # yyyy.mm.dd
            (0008,0020) AT S Acquisition Date       # yyyy.mm.dd
            (0008,0020) AT S Image Date             # yyyy.mm.dd
            (0008,0030) AT S Study Time             # hh.mm.ss.frac
            (0008,0031) AT S Series Time            # hh.mm.ss.frac
            (0008,0032) AT S Acquisition Time       # hh.mm.ss.frac
            (0008,0033) AT S Image Time             # hh.mm.ss.frac
            (0008,0060) AT S Modality               # CT,NM,MR,DS,DR,US,OT

            (0010,0010) AT S Patient Name
            (0010,0020) AT S Patient ID
            (0010,0030) AT S Patient Birthdate      # yyyy.mm.dd
            (0010,0040) AT S Patient Sex            # M, F, O for other
            (0010,1010) AT S Patient Age            # xxxD or W or M or Y

            (0018,0010) AT M Contrast/Bolus Agent   # or NONE
            (0018,0030) AT M Radionuclide
            (0018,0050) AN S Slice Thickness        # mm
            (0018,0050) AN M KVP
            (0018,0080) AN S Repetition Time        # ms
            (0018,0081) AN S Echo Time              # ms
            (0018,0082) AN S Inversion Time         # ms
            (0018,1120) AN S Gantry Tilt            # degrees

            (0020,1040) AT S Position Reference     # eg. iliac crest
            (0020,1040) AN S Slice Location         # in mm (signed)

            (0028,0010) BI S Rows
            (0028,0011) BI S Columns
            (0028,0030) AN M Pixel Size             # row\col in mm
            (0028,0100) BI S Bits Allocated         # eg. 12 bit for CT
            (0028,0101) BI S Bits Stored            # eg. 16 bit
            (0028,0102) BI S High Bit               # eg. 11
            (0028,0102) BI S Pixel Representation   # 1 signed, 0 unsigned

            (7FE0,0010) BI M Pixel Data             # as described by grp 0028

        The way in which the pixel data is stored can vary tremendously, though
thankfully most users and vendors use the simple unimaginative scheme that is
shown above, ie. 1 12 bit pixel stored in the low order part of a 16 bit word
with no attempt at packing more compactly. Following are some examples shown in
Appendix E of the standard. Note that when one adds the little/big endian
question the permutations mount!

        Bits Allocated = 16
        Bits Stored    = 12
        High Bit       = 11

                          |<------------------ pixel ----------------->|
            ______________ ______________ ______________ ______________
           |XXXXXXXXXXXXXX|              |              |              |
           |______________|______________|______________|______________|
            15          12 11           8 7            4 3            0

        ---------------------------

        Bits Allocated = 16
        Bits Stored    = 12
        High Bit       = 15

           |<------------------ pixel ----------------->|
            ______________ ______________ ______________ ______________
           |              |              |              |XXXXXXXXXXXXXX|
           |______________|______________|______________|______________|
            15          12 11           8 7            4 3            0

        ---------------------------

        Bits Allocated = 12
        Bits Stored    = 12
        High Bit       = 11

           ------ 2 ----->|<------------------ pixel 1 --------------->|
            ______________ ______________ ______________ ______________
           |              |              |              |              |
           |______________|______________|______________|______________|
            15          12 11           8 7            4 3            0

           -------------- 3 ------------>|<------------ 2 --------------
            ______________ ______________ ______________ ______________
           |              |              |              |              |
           |______________|______________|______________|______________|
            15          12 11           8 7            4 3            0

           |<------------------ pixel 4 --------------->|<----- 3 ------
            ______________ ______________ ______________ ______________
           |              |              |              |              |
           |______________|______________|______________|______________|
            15          12 11           8 7            4 3            0

        ---------------------------

        And so on ... refer to the standard itself for more detail.

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.
Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01


    2.2 ACR/NEMA DICOM 3.0

        ACR/NEMA Standards Publications

            No. PS 3.1-1992   <- DICOM 3 - Introduction & Overview
            No. PS 3.8-1992   <- DICOM 3 - Network Communication Support

            No. PS 3.2-1993   <- DICOM 3 - Conformance
            No. PS 3.3-1993   <- DICOM 3 - Information Object Definitions
            No. PS 3.4-1993   <- DICOM 3 - Service Class Specifications
            No. PS 3.5-1993   <- DICOM 3 - Data Structures & Encoding
            No. PS 3.6-1993   <- DICOM 3 - Data Dictionary
            No. PS 3.7-1993   <- DICOM 3 - Message Exchange
            No. PS 3.9-1993   <- DICOM 3 - Point-to-Point Communication

            No. PS 3.10-????  <- DICOM 3 - Media Storage & File Format
            No. PS 3.11-????  <- DICOM 3 - Media Storage Application Profiles
            No. PS 3.12-????  <- DICOM 3 - Media Formats & Physical Media

        DICOM (Digital Imaging and Communications in Medicine) standards are of
course the hot topic at every radiological trade show. Unlike previous attempts
at developing a standard, this one seems to have the potential to actually
achieve its objective, which in a nutshell, is to allow vendors to produce a
piece of equipment or software that has a high probability of communicating
with devices from other vendors.

        Where DICOM differs substantially from other attempts, is in defining
so called Service-Object Pairs. For instance if a vendor's MR DICOM conformance
statement says that it supports an MR Storage Class as a Service Class
Provider, and another vendor's workstation says that it supports an MR Storage
Class as a Service Class User, and both can connect via TCP/IP over Ethernet,
then the two devices will almost certainly be able to talk to each other once
they are setup with each others network addresses and so on.

        The keys to the success of DICOM are the use of standard network
facilities for interconnection (TCP/IP and ISO-OSI), a mechanism of association
establishment that allows for negotiation of how messages are to be
transferred, and an object-oriented specification of Information Objects (ie.
data sets) and Service Classes.

        Of course all this makes for a huge and difficult to read standard, but
once the basic concepts are grasped, the standard itself just provides a
detailed reference. From the users' and equipment purchasers' points of view
the important thing is to be able to read and match up the Conformance
Statements from each vendor to see if two pieces of equipment will talk.

        Just being able to communicate and transfer information is of course
not sufficient - these are only tools to help construct a total system with
useful functionality. Because a workstation can pull an image off an MRI
scanner doesn't mean it knows when to do it, when the image has become
available, to which patient it belongs, and where it is subsequently archived,
not to mention notifying the Radiology or Hospital Information System (RIS/HIS)
when such a task has been performed. In other words DICOM Conformance does not
guarantee functionality, it only facilitates connectivity.

        In otherwords, don't get too carried away with espousing the virtues of
DICOM, demanding it from vendors, and expecting it to be the panacea to create
a useful multi-vendor environment.

        Fred Prior ([e-mail]) has come up with the concept of a
User Conformance Statement to be generated by purchasers and to be satisfied by
vendors. The idea is that one describes what one expects and hence gives the
vendor a chance to realistically satisfy the buyer! Of course each such
statement must be tailored to the user's needs, and simply stapling a copy of
Fred's statement to a Request For Proposals is not going to achieve the desired
objective. Caveat empor.

        To get more information about DICOM:

           - Purchase the standards from NEMA.

           - Ftp the final versions of the drafts in electronic form
              one of the sites described below.

           - Follow the Usenet group comp.protocols.dicom.

           - Get a copy of "Understanding DICOM 3.0" $12.50 from Kodak.

           - Insist that your existing and potential vendors supply you
              with DICOM conformance statements before you upgrade or
              purchase, and don't buy until you know what they mean. Don't
              take no for an answer!!!!

        What is all this doing in an FAQ about medical image formats you ask ?
Well first of all, in many ways DICOM 3.0 will solve future connectivity
problems, if not provide functional solutions to common problems. Hence
actually getting the images from point A to B is going to be easier if everyone
conforms. Furthermore, for those of us with old equipment, interfacing it to
new DICOM conforming equipment is going to be a problem. In otherwords old
network solutions and file formats are going to have to be transformed if they
are going to communicate unidirectionally or bidirectionally with DICOM 3.0
nodes. One is still faced with the same old questions of how does one move the
data and how does one interpret it.

         The specifics of the DICOM message format are very similar to the
previous versions of ACR/NEMA on which it is based. The data dictionary is
greatly extended, and certain data elements have been "retired" but can be
ignored gracefully if present. The message itself can now be transmitted as a
byte stream over networks, rather than using a point-to-point paradigm
excusively (though the old point-to-point interface is available). This message
can be encoded in various different Transfer Syntaxes for transmission. When
two devices ("Application Entities" or AE) begin to establish an "Association",
they negotiate an appropriate transfer syntax. They may choose an Explicit
Big-Endian Transfer Syntax in which integers are encoded as big-endian and
where each data element includes a specific field that says "I am an unsigned
16 bit integer" or "I am an ascii floating-point number", or alternatively they
can fall back on the default transfer syntax which every AE must support, the
Implicit Little-Endian Transfer Syntax which is just the same as an old
ACR/NEMA message with the byte order defined once and for all.

        This is all very well if you are using DICOM as it was originally
envisaged - talking over a network, negotiating an association, and determining
what Transfer Syntax to use. What if one wants to store a DICOM message in a
file though ? Who is to say which transfer syntax one will use to encode it
offline ? One approach, used for example by the Central Test Node software
produced by Mallinkrodt and used in the RSNA Inforad demonstrations, is just to
store it in the default little-endian implicit syntax and be done with it. This
is obviously not good enough if one is going to be mailing tapes, floppies and
optical disks between sites and vendors though, and hence the DICOM group
decided to define a "Media Storage & File Format" part of the standard, the new
Chapter 10 which is about to be or has just been voted on.

        Amongst other things, this new part defines a generic DICOM file format
that contains a brief header, the "DICOM File Meta Information Header" which
contains a 128 byte preamble (that the user can fill with anything), a 4 byte
DICOM prefix "DICM", then a short DICOM format message that contains newly
defined elements of group 0002 in a specified Transfer Syntax, which uniquely
identify the data set as well as specifying the Transfer Syntax for the rest of
the file. The rest of the message must specify a single SOP instance which can
of course contain multiple images as folders if necessary. The length of the
brief message in the Meta Header is specified in the first data element as
usual, the group length.

Originally the draft of Part 10 specified the default Implicit Value
Representation Little Endian Transfer Syntax as the DICOM File Meta Information
Header Transfer Syntax, which is in keeping with the concept that it is the
default for all other parts of the standard. I am told however, though I
haven't seen it, that the final standard will have changed this to Explicit
Value Representation Little Endian Transfer Syntax. This seems like an
extremely irritating change to me but I guess purists have prevailed.

        So what choices of Transfer Syntax does one have and why all the fuss ?
Well the biggest distinction is between implicit and explicit value
representation which allows for multiple possible representations for a single
element, in theory at least, and perhaps allows one to make more of an unknown
data element than one otherwise could perhaps. Some purists (and Interfile
people) would argue that the element should be identified descriptively, and
there is nothing to stop someone from defining their own private Transfer
Syntax that does just that (what a heretical thought, wash my mouth out with
soap). With regard to the little vs. big endian debate I can't see what the
fuss is about, as it can't really be a serious performance issue.

        Perhaps more importantly in the long run, the Transfer Syntax mechanism
provides a means for encapsulating compressed data streams, without having to
deal with the vagaries and mechanics of compression in the standard itself. For
example, if DICOM version 3.0, in addition to the "normal" Transfer Syntaxes, a
series are defined to correspond to each of the Joint Photographic Experts
Group (JPEG) processes. Each one of these Transfer Syntaxes encodes data
elements in the normal way, except for the image pixel data, which is defined
to be encoded as a valid and self-contained JPEG byte stream. Both reversible
and irreversible processes of various types are provided for, without having to
mess with the intricacies of encoding the various tables and parameters that
JPEG processes require. Presumably a display application that supports such a
Transfer Syntax will just chop out the byte stream, pass it to the relevant
JPEG decode, and get an uncompressed image back. More importantly, an archive
server can store the image and retrieve it without ever having to know anything
about how the image pixel data is encoded. Contrast this approach with that
taken by those defining the TIFF (Tagged Image File Format) for general imaging
and page layout applications. In their version 6.0 standard they attempted to
disassemble the JPEG stream into its various components and assign each to a
specific tag. Unfortunately this proved to be unworkable after the standard was
disseminated and they have gone back to the drawing board.

        Now one may not like the JPEG standard, but one cannot argue with the
fact that the scheme is workable, and a readily available means of reversible
compression has been incorporated painlessly. How effective a compression
scheme this is remains to be determined, and whether or not the irreversible
modes gain wide acceptance will be dictated by the usual medico-legal paranoia
that prevails in the United States, but the option is there for those who want
to take it up. There is of course no reason why private compression schemes
cannot be readily incorporated using this "encapsulation" mechanism, and to
preserve bandwidth this will undoubtedly occur. This will not compromise
compatibility though, as one can always fall back to a default, uncompressed
Transfer Syntax. The DICOM Working Group IV on compression will undoubtedly
bring out new possibilities. Currently there is a lot of interest in RLE (Run
Length Encoded) compression, particularly from the Ultrasound group.

        In order to identify all these various syntaxes, information objects,
and so on, DICOM has adopted the ISO concept of the Unique Identifier (UID)
which is a text string of numbers and periods with a unique root for each
organization that is registered with ISO and various organizations that in turn
register others in a hierarchical fashion. For example 1.2.840.10008.1.2 is
defined as the Implicit VR Little Endian Transfer Syntax. The 1 identifies ISO,
the 2 is the ISO member body branch, the 840 is the specific member body
country code, in this case ANSI, and the 10008 is registered by ANSI to NEMA
for DICOM.  UID's are also used to uniqely identify non-DICOM specific things,
such as information objects. These are constructed from a prefix registered to
the supplier or vendor or site, and a unique suffix that may be generated from
say a date and time stamp (which is not to be parsed). For example an instance
of a CT information object might have a UID of
1.2.840.123456.002.999999.940623.170717 where a (presumably US) vendor
registered 123456, and the modality generated a unique suffix based on its
device number, patient hospital id, date and time, which have no other
significance other than to create a unique suffix.

        The other important new concept that DICOM introduced was the concept
of Information Objects. In the previous ACR/NEMA standard, though modalities
were identified by a specific data element, and though there were rules about
which data elements were mandatory, conditional or optional in ceratin
settings, the concept was relatively loosely defined. Presumably in order to
provide a mechanism to allow conformance to be specified and hence ensure
interoperability, various Information Objects are defined that are composed of
sets of Modules, each module containing a specific set of data elements that
are present or absent according to specific rules. For example, a CT Image
Information Object contains amongst others, a Patient module, a General
Equipment module, a CT Image module, and an Image Pixel module. An MR Image
Information module would contain all of these except the CT Image module which
would be replaced by an MR Image module. Clearly one needs descriptive
information about a CT image that is different from an MR image, yet the
commonality of the image pixel data and the patient information is recognized
by this model.

        Hence, as described earlier, one can define pairs of Information
Objects and Services that operate on such objects (Storage, Query/Retrieve,
etc.) and one gets SOP classes and instances. All very object oriented and
initially confusing perhaps, but it provides a mechanism for specifying
conformance. From the point of view of an interpreters of a DICOM compatible
data stream this means that for a certain instance of an Information Object,
certain information is guaranteed to be in there, which is nice. As a creator
of such a data stream, one must ensure that one follows all the rules to make
sure that all the data elements from all the necessary modules are present.
Having done so one then just throws all the data elements together, sorts them
into ascending order by group and element order, and pumps them out. It is a
shame that the data stream itself doesn't reflect the underlying order in the
Information Objects, but I guess they had to maintain backward compatibility,
hence this little bit of ugliness. This gets worse when one considers how to
put more than one object in a folder inside another object.

        At this point I am tempted to include more details of various different
modules, data elements and transfer syntaxes, as well as the TCP/IP mechanism
for connection. However all this information is in the standard itself which is
readily available electronically from the ftp sites, and in the interests of
brevity I will not succumb to temptation at this time.

    2.3 Papyrus

        Papyrus is an image file format based on ACR/NEMA version 2.0. It was
developed by the Digital Imaging Unit of the University Hospital of Geneva for
the European project on telemedicine (TELEMED project of the RACE program),
under the leadership of Dr. Osman Ratib ([e-mail]). The University
Hospital of Geneva uses Papyrus for their hospital-wide PACS.

        The medical file format component of Papyrus version 2 extended the
ACR/NEMA format, particularly in order to reference multiple images by placing
folder information referencing ACR-NEMA data sets in a shadow (private) group.
Contributing to the development of DICOM 3, the team are updating their format
to be compatible with the offline file format provisions of the draft Part 10
of DICOM 3 in Papyrus version 3.

        The specifications, toolkit and image manipulation software that is
Papyrus aware, Osiris, is available for the Mac, Windows, and Unix/X11/Motif by
ftp from ftp://expasy.hcuge.ch/pub/Osiris.

See also Papyrus and Osiris ftp site.

        Further information is available in printed form. Contact
[e-mail] (Yves Ligier).

    2.4 Interfile V3.3

        Interfile is a "file format for the exchange of nuclear medicine image
data" created I gather to satisfy the needs of the European COST B2 Project for
the transfer of images of quality control phantoms, and incorporates the AAPM
(American Association of Physicists in Medicine) Report No. 10, and has been
subsequently used for clinical work.

        It specifies a file format composed of ascii "key-value" pairs and a
data dictionary of keys. The binary image data may be contained in the same
file as the "administrative information", or in a separate file pointed to by a
"name of data file" key. Image data may be binary integers, IEEE floating point
values, or ascii and the byte order is specified by a key "imagedata byte
order". The order of keys is defined by the Interfile syntax which is more
sophisticated than a simple list of keys, allowing for groups, conditionals and
loops to dictate the order of key-value pairs.

        Conformance to the Interfile standard is informally described in terms
of which types of image data types, pixel types, multiple windows, special
Interfile features including curves, and restriction to various maximum
recommended limits.

        Interfile is specifically NOT a communications protocol and strictly
deals with offline files. There are efforts to extend Interfile to include
modalities other than nuclear medicine, as well as to keep ACR/NEMA and
Interfile data dictionaries in some kind of harmony.

        A sample list of Interfile 3.3 key-value pairs is shown here to give
you some idea of the flavor of the format. The example is culled from part of a
Static study in the Interfile standard document and is not complete:

                !INTERFILE :=
                !imaging modality :=nucmed
                !version of keys :=3.3
                data description :=static
                patient name :=joe doe
                !patient ID  :=12345
                patient dob :=1968:08:21
                patient sex :=M
                !study ID :=test
                exam type :=test
                data compression :=none
                !image number :=1
                !matrix size [1] :=64
                !matrix size [2] :=64
                !number format :=signed integer
                !number of bytes per pixel :=2
                !image duration (sec) :=100
                image start time :=10:20: 0
                total counts :=8512
                !END OF INTERFILE :=

        One can see how easy such a format would be to extend, as well as how
it is readable and almost useable without reference to any standard document or
data dictionary.

        Undoubtedly ACR/NEMA DICOM 3.0 to Interfile translators will soon
proliferate in view of the fact that many Nuclear Medicine vendors supply
Interfile translators at present.

        To get hold of the Interfile 3.3 standard, see the sources, contacts
and mailing list described later in this document.

    2.5 Qsh

        Qsh is a family of programs for manipulating images, and it defines an
intermediate file format. The following information was derived with the help
of one of the authors [e-mail](Chip Maguire):

        Uses an ASCII key-value-pair (KVP sic.) system, based on the AAPM
Report #10 proposal. This format influenced both Interfile and ACR-NEMA
(DICOM). The file format is referred to as "IMAGE" in some of their articles
(see references). The header and the image data  are stored as two separate
files with extensions *.qhd and *.qim respectively.

        Qsh is available by anonymous ftp (see Sources section). This is a
seriously large tar file, including as it does some sample images, and lots of
source code, as well as some post-script documents. Subtrees are available as
separate tar files.

        QSH's Motif-based menu system (qmenu) will work with OpenWindows 3.0 if
SUN patch number 100444-54 for SUNOS 4.1.3 rev. A is applied. The patch is
available from ftp://sunsolve1.sun.com (192.9.9.24).

        The image access subroutines take the same parameters as the older
/usr/image package from UNC, however, the actual subroutines support the qsh
KVP and image data files.

        The frame buffer access subroutines take the same parameters as the
Univ. of Utah software (of the mid.  1970s). The design is based on the use of
a virtual frame buffer which is then implemented via a library for a specific
frame buffer.  There exists a version of the the display routines for X11.

        Conversions are not supported any longer, instead there is a commercial
product called InterFormat. InterFormat includes a qsh to Interfile conversion,
along with DICOM to qsh, and many others. Information is available from
[e-mail] (David Reddy) (see InterFormat in the Sources
section).

        [Editorial note: this seems a bit of a shame to me - the old
distribution included lots of handy bits of information, particularly on
driving tape drives. I am advised however that the conversion stuff was pulled
out because people wanted it supported, the authors were worried they were
disclosing things perhaps they ought not to be, and NYU had switched to using
InterFormat themselves anyway. DAC.]

        The authors of the qsh package are:

               - [e-mail] (Gerald Q. (Chip) Maguire)
               - [e-mail] (Marilyn E Noz)

        The following references are helpful in understanding the philosophy
behind the file format, and are included in postscript form in the qsh ftp
distribution:

        @Article[noz88b,
                Key=<noz88b>,
                Author=<M. E. Noz and G. Q. Maguire Jr.>,
                Title=<QSH: A Minimal but Highly Portable Image Display
                       and Processing Toolkit>,
                Journal=<Computer Methods and Programs in Biomedicine>,
                volume=<27>,
                month=<November>,
                Year=<1988>,
                Pages=<229-240>
        ]
        @Article[maguire89e,
                Key=<maguire>,
                Author=<G.Q. Maguire Jr., and M.E. Noz>,
                Title=<Image Formats: Five Years after the AAPM Standard Format
                for Digital Image Interchange>,
                Journal=<Medical Physics>,
                volume=<16>,
                month=<September/October>,
                year=<1989>,
                pages=<818-823>,
                comment=<Also as CUCS-369-88>
        ]

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.
Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01


3.  Proprietary Formats

    3.1 General

        3.1.1 SPI (Standard Product Interconnect)

              Used on:

                - Siemens CT Somatom Plus
                - Siemens MR Impact
                - Siemens MR SP,SP/4000,Vision
                - Philips MR S5 (exported images)
                - ? what else ?

              SPI is a standard based on the old ACR/NEMA 1 standard, devised I
gather by Siemens and Philips, for use in a PACS environment. Who currently
maintains it and whether or not Sienet PACS systems are based on it, I am not
certain. Many machines in the workplace use it in some shape or form, or can
export files in SPI format. I gather it has been around since 1987 or so, but I
do not yet have access to the reference documents, nor permission to disclose
their contents, so much of the following is guess work or hearsay from Usenet.

               Like the ACR/NEMA standard, SPI is designed to define
interconnections between pieces of equipment from the physical level through to
the application level. Where appropriate it utilized relevant parts of
ACR/NEMA. Unlike ACR/NEMA, I gather that SPI is aware of the concept of
networks, objects containing information, the need to uniquely identify
instances of objects, and defines an offline file format. Thus in many ways it
sounds like the missing link between ACR/NEMA 2.0 and DICOM 3.0.

              SPI makes use of ACR/NEMA data elements and groups, and in
addition provides "shadow" private odd-numbered groups as dictated by the
ACR/NEMA standard for the purpose of storing additional items of information,
including a means of uniquely identifying objects, as well as allowing for
enumerated values for elements beyond those defined by ACR/NEMA. SPI also
defines a byte order for offline storage of data streams. Integers are stored
in little endian format (least significant byte first).

              The private groups mechanism works as follows. For each odd
numbered group (other than 0x0001,0x0003,0x0005,0x0007 and 0xffff), the
elements 0x00nn in the range 0x0010 through 0x00ff contain a single valued
string identification code that identifies the creator of the range of elements
0xnn00 through 0xnnff. Neat eh ? For example:

    (0x0009,0x0010) PrivateCreatorDataElement
    (0x0009,0x0011) PrivateCreatorDataElement
    ...
    (0x0009,0x1000) DavidElement1
    (0x0009,0x1001) DavidElement2
    ...
    (0x0009,0x1100) HarryElement1
    (0x0009,0x1101) HarryElement2

              You get the idea. The nice thing about this scheme is that each
creator dictionary considers its elements numbered from 0x0000, but these will
be remapped to a block of elements depending on exactly which
PrivateCreatorDataElement is used in the particular data set. Hence multiple
groups from different creators can co-exist happily in the same data set, and
vary in position between data sets.

              Note that the group number IS taken into consideration ... a
private element with the same element offset and the same creator will have a
different meaning depending on which group it is in.

              SPI uses this concept extensively and defines a large dictionary
with different creators with convoluted names for different modalities and PACS
operations. A few sample elements are described here. Particularly important
are those elements for purposes that were not envisaged when ACR/NEMA 1 was
written, but are necessary to create valid DICOM 3 data sets. Such things as
FlipAngle for MR scans for example. Note that the SPI UID is not the same as a
DICOM UID, but presumably it is unique ! Note also that the creator of "SPI
RELEASE 1" is the same as "SPI Release 1" and "SPI" ... presumably someone
messed up between machines or modalities or manufacturers. For a more extensive
SPI data dictionary see the dicom3tools package from release 0.08 onwards. The
value representation fields are shown here using the modern DICOM equivalents
rather than the older, less specific ACR/NEMA names. The "owner" is what is
used as the string value of the PrivateCreatorDataElement when a range of
elements in a group is claimed.

Element     Owner                 Name                  VR VM

(0009,0010) SPI                   Comments              LO  1
(0009,0015) SPI                   UID                   LO  1
(0009,0010) SIEMENS MED           RecognitionCode       LO  1

(0011,0010) SPI RELEASE 1         Organ                 LO  1
(0011,0015) SPI RELEASE 1         AllergyIndication     LO  1
(0011,0020) SPI RELEASE 1         Pregnancy             LO  1
(0011,0010) SIEMENS CM VA0  CMS   RegistrationDate      DA  1
(0011,0011) SIEMENS CM VA0  CMS   RegistrationTime      TM  1
(0011,0023) SIEMENS CM VA0  CMS   UsedPatientWeight     IS  1

(0013,0020) SIEMENS CM VA0  CMS   PatientName           LO  1
(0013,0022) SIEMENS CM VA0  CMS   PatientId             LO  1
(0013,0030) SIEMENS CM VA0  CMS   PatientBirthdate      LO  1
(0013,0031) SIEMENS CM VA0  CMS   PatientWeight         DS  1
(0013,0035) SIEMENS CM VA0  CMS   PatientSex            LO  1
(0013,0040) SIEMENS CM VA0  CMS   ProcedureDescription  LO  1
(0013,0042) SIEMENS CM VA0  CMS   RestDirection         LO  1
(0013,0044) SIEMENS CM VA0  CMS   PatientPosition       LO  1

(0019,0010) SIEMENS CM VA0  CMS   NetFrequency          DS  1
(0019,0011) SIEMENS CM VA0  ACQU  SequenceFileName      LO  1
(0019,0021) SIEMENS CT VA0  GEN   Exposure              DS  1
(0019,0026) SIEMENS CT VA0  GEN   GeneratorVoltage      DS  1
(0019,0050) SIEMENS MR VA0  GEN   NumberOfAverages      IS  1
(0019,0060) SIEMENS MR VA0  GEN   FlipAngle             DS  1
(0019,0012) SIEMENS MR VA0  COAD  MagneticFieldStrength DS  1

(0021,0010) SIEMENS MED           Zoom                  DS  1
(0021,0011) SIEMENS MED           Target                DS  2
(0021,0020) SIEMENS CM VA0  CMS   FoV                   DS  2
(0021,0060) SIEMENS CM VA0  CMS   ImagePosition         DS  3
(0021,0061) SIEMENS CM VA0  CMS   ImageNormal           DS  3
(0021,006a) SIEMENS CM VA0  CMS   ImageRow              DS  3
(0021,006b) SIEMENS CM VA0  CMS   ImageColumn           DS  3
(0021,0039) SIEMENS MR VA0  GEN   SlabThickness         DS  1
(0021,0070) SIEMENS MR VA0  GEN   NumberOfEchoes        IS  1

    3.2 CT

        3.2.1 General Electric

              Now we get to the meaty part. After years of being faced with the
problem of either a) hours of detective work, or b) tediously tracking down the
name of the responsible person and exercising a non-disclosure agreement,
General Electric (or Generous Electric as I heard them described the other day)
now really are being generous, as well as sensible, and are making their image
format description documents freely available. For details see the contact
section later on. In the meantime, both for historical completeness,
educational purposes, and for those who can't wait for document to come in the
mail, a summary of the relevant formats and decompression algorithms is
provided here.

              3.2.1.1 CT 9800

                      3.2.1.1.1 Image data

                                - "block format" header
                                - perimeter encoding
                                - optional DPCM compression
                                - Data General host (various)
                                - RDOS (yuck !)

                                Almost everyone in this field has at some stage
encountered the dreaded CT 9800 format. The world is divided into two groups of
people ... those who have seen the documents or the critical piece of code in
another program or have been given a handy hint, and those who will never
figure out the format themselves.

                                Essentially the format fits into the "block
format" described earlier, with pointers to each of the major header
components. Rarely, if ever, does one encounter a file that doesn't have the
same size blocks in the same place, so most people treat it as a fixed layout.
I believe that reformatted images may have another header stored in there, but
I have never tested for it.

                                The data itself is stored in one of two forms
depending on whether compression is selected or not during archival. In the
uncompressed form, a type of perimeter encoding is used (see later section) in
which for an essentially circular object, the outer parts of a rectangular
image are discarded (and expected to be filled in with a background pixel value
during reconstitution of the image). In the case of the CT9800 then, the image
pixel data is interpreted using a map, which contains an entry for each row of
the image (either 256, 320 or 512 entries) which specifies the length of the
row that is actually stored, centered about the midline of the image. This
obviously saves a lot of space.

                                 If compression is selected on one of the later
model machines, then a form of Differential Pulse Code Modulation is used, in
which advantage is taken of the fact that not all the bits of a 16 bit word are
need to store a CT value. I gather only 12 bits of data are actually
significant, but one can theoretically represent 15 using this scheme.
Essentially, the first 16 bit word is read and used as is. Then another byte is
read. If its most significant bit is set, then the remaining 7 bits represent a
signed difference value relative to the previous pixel. If its most significant
bit is not set, then the difference must have exceeded the range of 7 bits, and
hence the next byte is read to complete a valid 16 bit word (15 bits really)
which is the actual pixel value. The really neat thing about this scheme is
that the same algorithm can be used for compressed or uncompressed data as an
uncompressed stream of words will never have the most significant bit set !

                                  The following piece of C++ code pulled out of
a CT9800 to DICOM translator will give you the general idea. Note that the
perimeter encoding map has already been read in. Note in particular the need to
deal with sign extension of the difference value. Also note that the code
doesn't handle the first pixel specially because its high bit will not be set.

static void
copy9800image(ifstream& instream,DC3ofstream& outstream,
          Uint16 resolution,Uint16 *map)
{
    unsigned i;
    Int16 last_pixel;

    last_pixel=0;
    for (i=0; i<resolution; ++i) {
        unsigned line    = map[i];
        unsigned start    = resolution/2-line;
        unsigned end    = start+line*2;
        unsigned j;

        // Pad the first "empty" part of the line ...
        for (j=0; j<start; j++) outstream.write16(0);

        // Copy the middle of the line (compressed or uncompressed)
        while (start<end) {
            unsigned char byte;
            instream.read(&byte,1);
            if (!instream) break;
            if (byte & 0x80) {
                signed char delta;
                if (byte & 0x40) {
                    delta=byte;
                }
                else {
                        delta=byte & 0x3f;
                }
                last_pixel+=delta;
            }
            else {
                last_pixel=byte << 8;
                instream.read(&byte,1);
                if (!instream) break;
                last_pixel+=byte;
            }
            outstream.write16((Uint16)last_pixel & 0x0fff);
            ++start;
        }

        // Pad the last "empty" part of the line ...
        for (j=end; j<resolution; j++) outstream.write16(0);
    }
}

                                What about the rest of the header information
and where is this map stored anyway ? Well, the file is described as a series
of 256 by 16 bit word blocks, blocks numbered from 0, words numbered from 1,
integers are 16 bit words, as follows:

        block 0 - global header

               word 34   - Int - pointer to global header
               word 35   - Int - pointer to exam header
               word 36   - Int - pointer to image header
               word 37   - Int - pointer to image header2
               word 38   - Int - pointer to image map
               word 39   - Int - pointer to image data
               word 40   - Int - number of blocks in global header
               word 41   - Int - number of blocks in exam header
               word 42   - Int - number of blocks in image header
               word 43   - Int - number of blocks in image header2
               word 44   - Int - number of blocks in image map
               word 45   - Int - number of blocks in image data

                                Now almost always the layout is as follows, for
non-reformatted images:

        block 0 - global header
        block 1 - exam header
        block 2 - image header
        block 3 - image header 2
        block 4 - image map
        block 6 - image data

                                For reformatted images the layout is said to be
different, but I have never seen a description of the contents of the so-called
"arrange header", nor do I know where in the global header the pointer and
length are stored:

        block 0 - global header
        block 1 - exam header
        block 2 - image header
        block 3 - image header 2
        block 4 - arrange header
        block 9 - image map
        block 11 - image data

                                Some of the more important contents of the
various headers are listed here. For more complete information get the
documents from GE or study any one of a number of programs kicking around to
dump the header of this kind of file (see sources later). Integers are 16 bit
words, ascii strings are Fortran style specifications with two characters per
word, and reals are 4 bytes long (see Host machines - Data General):

        block 0 - global header

               word 17-23    - 7A2  - file name

        block 1 - exam header

               word  4       - Int  - exam number
               word  5-11    - 7A2  - exam number
               word  12-17   - 6A2  - patient id
               word  18-32   - 15A2 - patient name

        block 2 - image header

               word  11      - Int  - position (study) number
               word  13      - Int  - group type (2=scout,3=standard,4=dynamic)
               word  14      - Int  - group number
               word  47      - Int  - scan number
               word  48      - Int  - image number
               word  50      - Int  - patient orientation (1=head first,2=feet)
               word  51      - Int  - AP orientation (1=prone,2=sup,3=lt,4=rt)
               word  55      - Int  - contrast (0=no,1=yes)
               word  93-94   - Real - gantry tilt
               word  95-96   - Real - table height mm
               word  97-98   - Real - axial table location mm
               word  124     - Int  - image size (256,320,512) NOT FOR SCOUTS
               word  132     - Int  - detectors/view        - width  for scouts
               word  137     - Int  - compressed views/scan - height for scouts
               word  144-145 - Real - X diameter of recon mm
               word  146-147 - Real - Y diameter of recon mm
               word  155-156 - Real - magnification factor
               word  157-158 - Real - X center
               word  159-160 - Real - Y center
               word  175     - Int  - image map used (1=yes,2=no)
               word  218     - Int  - file type (1=prospective,2=scout,
                                      3=retrospective,4=segmented,
                                      5=screen save,6=plot)
               word  219     - Int  - data range (number of bits)
               word  236     - Int  - scout orientation (0=ap,1=lateral)
                                      (the 9800 rotates the scout magically)

                                It is important to check the filetype and image
map used entries, particularly if trying to read scouts rather just prospective
images. If the map is not in use, it is filled with zeroes and hence if the
flag is not checked a simplistic demapping algorithm will fail. Furthermore the
number of rows and columns in the image is not specified as such. For
prospective images, the imagesize field is valid for both (images are square).
For scouts, one must use the detectors/view field for the width and the
compressed views/scan field as the height.

                                The filename entry is quite useful. Therein is
stored the RDOS filename of the image, which follows the following convention:

        seeeeeppdd.tt

        s     = originating scan station id
        eeeee = exam number
        pp    = prs number (position related set)
        dd    = image number
        tt    = file type
                YP = prospective
                YV = scout
                YR = retrospective
                YG = segmented recon
                YS = screen save
                YL = plot
                YF = reformatted

        eg. B038500165.YP

                                Having said this, my GE 9800 stores its scouts
on tape at least with no file extension at all, rather than the .YV that it is
supposed to use.

                      3.2.1.1.2 Tape format

                                Probably more CT images have been exchanged for
clinical and research purposes using GE 9800 9-track magnetic tapes than any
other means. These things are just ubiquitous, particularly considering the
proliferation of services providing 3D reconstruction and fabrication a few
years ago. Fortunately the format is easy to deal with. The tapes are produced
on a primitive DG tape drive and hence are never more than 1600bpi. The first
thing on the tape is a directory consisting of two 4096 word (8192 byte)
records, then two EOF marks, then 20" of blank tape (because the directory
keeps getting updated) followed by image files each separated by an EOF mark
and finally an additional EOF mark after the last file.

                                I won't describe the tape directory format here
unless someone specifically asks for it, though it is very simple. I usually
just read everything on the tape and sort the files out later. Remember that
their filenames are stored in the global header.

                                Don't forget to set the input magnetic tape
record size to 8192 bytes when you are copying these files. If you don't do
this some systems quietly truncate each record to some default size. It took me
a week to figure out why my files were screwed up the first time I tried this
on a DG under AOS/VS (I was desperate and using a networked Signa to read files
off a non-networked 9800).

                                A simple script to read an entire tape from a
SCSI tape drive /dev/nrst1 under SunOS, which will peek in each image file to
extract the correct filename (simpler than trying to decipher the directory)
looks like
this:

#!/bin/sh

echo "Rewinding"
mt -f /dev/nrst1 rewind

echo "Extracting directory ..."
dd if=/dev/nrst1 ibs=8192 of=TAPEDIR

while dd if=/dev/nrst1 ibs=8192 of=tape.tmp
do
    name=`dd if=tape.tmp ibs=16 skip=2 count=1 2>/dev/null`
    if [ -z "$name" ]; then break; fi
    mv tape.tmp $name
    echo "Extracted $name"
done

echo "Rewinding"
mt -f /dev/nrst1 rewind
echo "Finished"

                      3.2.1.1.2 Raw data

                                No idea about this one ... I have never had the
need or seen any documention. Anyone who does or has please fill in this space.

              3.2.1.2 CT Advantage - Genesis

                      General Electric now uses the same Sun based architecture
for its Advantage CT and Signa 5X MR family, referred to as Genesis, and hence
the general details of this scheme will be discussed under the GE Signa 5X -
Genesis section. Specifics related to the CT modality will be described here.

                      3.2.1.2.1 Image data

                                The Image Extract Tool is used in the same way
as on the Signa to extract an image from the database into a single file,
either asis or using the requested compression and packing mode. The Genesis
file contains headers consisting of several components in common with MR and
then a specific CT or MR header. Theroetically, one should be able to use
"/usr/g/insite/bin/ximg -g" to extract a prototype C header file describing the
file format, as on the Signa, though last time I tried this on a High Speed
Advantage this didn't work. Some of the more interesting fields in the CT image
header include:

        image header - for CT (1020 bytes long):

                26  - float    - slice thickness (mm)
                30  - short    - image matrix size - X
                32  - short    - image matrix size - Y
                34  - float    - display field of view - X
                38  - float    - display field of view - Y
                42  - float    - image dimension - X
                46  - float    - image dimension - Y
                50  - float    - pixel size - X
                54  - float    - pixel size - Y
                58  - char[14] - pixel data ID
                72  - char[17] - iv contrast agent
                89  - char[17] - oral contrast agent
                194 - float    - table start Location
                198 - float    - table end Location
                202 - float    - table speed (mm/sec)
                206 - float    - table height
                224 - float    - gantry tilt (degrees)

                      3.2.1.2.2 Archive format

                                See the Archive format for the Signa 5X.

                      3.2.1.2.3 Raw data

                                Again, unknown. Please fill in this space.

              3.2.1.3 Pace

                      I don't have one of these, but I do have the Japanese
documents with English annotations. Anyone who can send me a few sample files
on a floppy or something, please let me know, so I can test out the format and
elaborate on it here.

              3.2.1.4 Sytec

                      I don't have one of these either, and it turns out that
the format is NOT the same as the Pace as GE Milwaukee initially thought. The
format may be shared with the Vectra, but this is not known for certain. I do
have a few sample images and have worked out many of the values in the headers.
The format may be available from Yokogawa in Japan. Milwaukee apparently
doesn't have it.

                      The host is an MS-DOS clone using the J-DOS operating
system, a Japanese version of DOS to handle 16 bit Kanji characters. Alan
Rowberg tells me it has a 5.25" drive that writes disks that are unreadable by
anything else in the universe.

                      The images have a header of 3752 bytes and are followed
by 16-bit signed integers. The surround is -1500 which is probably -1500 H.U.
The sample files I ahd did not use any form of compression.

                      The data formats are big-endian. Fortuitously the
date/time format is the same as unix ... a 32 bit unsigned integer containing
seconds since an epoch of 00:00:00 GMT 1 Jan 1970. Floats are IEEE format as
follows:

    bit  31        sign (s)    (0 is +ve)

    bits 30-23    exponent (e)
            - unsigned integer
            - e == 0 for denormalized numbers
            - 0 < e < 255 for normalized numbers
            - e == 255 for other reserved operands

    bits 22-0    significand (f)

    Normalized numbers:
        Exponent:
            - bias 127
            - range 0 < e < 255
        Significand:
            - interpreted as 1.f
            - range 1.0 <= f < 2.0

        (-1)^s * 2^(e-127) * 1.f

    Denormalized numbers:
        Exponent:
            - e == 0
            - bias 126
        Significand:
            - interpreted as 0.f
            - range f != 0

        (-1)^s * 2^(-126) * 0.f

    Signed Infinities:
        - e == 255
        - f == 0

    Not-a-numbers:
        - e == 255
        - f != 0

                      The head first/feet first and prone/supine fields in the
Sytec file are not known. The sense and identification of corners in the Sytec
sample files was done by guess work, and may be wrong if the samples weren't
scanned head first supine, and the images are not supposed to be looked at from
bottom up in the usual convention.

                      The header is 3752 bytes long. The known header values
are (byte offsets from 0):

      Offset   Type         Meaning               Units or values

        7      string       ModelNumber

        126    string       Organization
        204    string       PatientID
        217    string       PatientName

        328    datetime     ExamDateTime
        402    string       ExamDescription
        425    string       Modality
        444    string       ExamStationID

        1164   int16        ExamNumber
        1166   int16        SeriesNumber
        1172   datetime     SeriesDate
        1176   string       SeriesDescription
        1206   string       SeriesStationID

        1224   int16        ScanType                # 1=axial,3=scout
        1240   string       AnatomicalReference

        1280   float32      SeriesStartLocation
        1288   float32      SeriesEndLocation

        2192   u_int16      ImageExamNumber
        2194   u_int16      ImageSeriesNumber
        2196   u_int16      ImageNumber
        2204   datetime     ScanDateTime
        2208   float32      ScanDuration            #? secs
        2212   float32      SliceThickness          # mm
        2216   u_int16      XMatrix
        2218   u_int16      YMatrix
        2220   float32      FieldOfView             # mm
        2224   float32      ScoutLength             # mm
        2228   float32      XDimension              # mm
        2232   float32      YDimension              # mm
        2236   float32      XPixelSize              # mm
        2240   float32      YPixelSize              # mm

        2310   u_int16      ScoutOrientation        # 0=none,1=ap,2=lateral
        2316   float32      TablePosition           # mm
        2320   float32      SliceCenterX            # mm
        2324   float32      SliceCenterY            # mm
        2328   float32      SliceCenterZ            # mm
        2332   float32      NormalVectorX           # unitized
        2336   float32      NormalVectorY           # unitized
        2340   float32      NormalVectorZ           # unitized
        2344   float32      TopRightHandCornerX     # mm
        2348   float32      TopRightHandCornerY     # mm
        2352   float32      TopRightHandCornerZ     # mm
        2356   float32      TopLeftHandCornerX      # mm
        2360   float32      TopLeftHandCornerY      # mm
        2364   float32      TopLeftHandCornerZ      # mm
        2368   float32      BottomLeftHandCornerX   # mm
        2372   float32      BottomLeftHandCornerY   # mm
        2376   float32      BottomLeftHandCornerZ   # mm
        2384   float32      ScoutStartLocation      # mm
        2388   float32      ScoutEndLocation        # mm
        2408   int32        GeneratorVoltage        # kVP
        2412   int32        TubeCurrent             # mA
        2416   float32      GantryTilt              # degrees

        2716   float32      XReconOffset            # mm
        2720   float32      YReconOffset            # mm

        3256   int32        BitsPerSample
        3264   int32        DefaultWindowWidth
        3268   int32        DefaultWindowLevel

        3.2.2 Siemens

              3.2.1.1 Somatom DR

                      - NOT in SPI format
                      - fixed format
                      - files 133120 bytes (for 256 square images)
                      - image pixel data 256*256*2 little endian
                      - image pixel offset 2048 bytes
                      - same for axial images and topograms (scouts)

                      This description pertains to the DR family, and possibly
also earlier Siemens CT models, but I have no files from these to test.

                      The files are in fixed format (cf. the early Magnetom
format which is similar, but has block pointers) with three major blocks of
entries:

        - binary data      - offset 0    - 512 bytes
        - text overlay     - offset 512  - 960 bytes plus 676 bytes free
        - image pixel data - offset 2048 - 131072 bytes

                      The binary data block is filled with the usual cryptic
enumerated values and useful parameters. Some of the more interesting ones are:

        - binary data block:

                66  - byte        - archive mode (0=raw data,B=256,C=512)
                67  - byte        - archive mode (0=uncompressed,
                                    2=compressed)

                72  - short       - matrix size (256 or 512)

                130 - byte        - scan mode (P=image data,R=raw data)
                131 - byte        - scan mode (0=tomogram,Q=quick,S=serial,
                                    C=cardiac,T=topogram,X=test,H=chronogram)
                132 - short       - fov - mm
                134 - short       - scan time - secs * 10
                136 - short       - kv
                138 - short       - dose - maS
                140 - short       - slice thickness - mm
                142 - short       - gantry tilt - degrees
                144 - short       - table position - mm
                146 - short       - table height - mm
                148 - short       - scan mode (1=standard(360),
                                    2=quickscan(240),4=topogram)

                236 - short       - view direction (1=cranial,-1=caudal)
                238 - byte        - head position (0=head first,
                                    1=feet first)
                239 - byte        - patient position (0=supine,
                                    1=prone,2=r lat dec,3=l lat dec)

                310 - short       - window width  A
                312 - short       - window center A
                314 - short       - window width  B
                316 - short       - window center B

                      Unfortunately, the patient identification information is
NOT stored in the binary data block, rather one has to extract it from the
image text overlay block, which consists of 960 characters (24 lines of 40
characters WITHOUT carriage control characters) in a fixed format. This is
where what you see overlayed on the filmed images is stored. Some of these
values are duplicates of what is in the binary data block, but things like the
patient name and so on are here and nowhere else :(

                    0123456789012345678901234567890123456789

                0   SOMATOM DR2       ST. ELSEWHERE GEN HOSP
                40  999999-9999  JOHN DOE                EF2
                80  01-JAN-90        FRONT               35B
                120 13:31:22                            H/SP
                160
                200 SCAN 60                             L
                240                                     E
                280                                     F
                320                                     T
                360
                400
                440
                480
                520
                560
                600
                640
                680
                720 TI 5
                760 KV 125
                800 AS .35
                840 SL 2
                880 GT 0
                920 TP 144

        - text overlay block: (some of this is guess work)

                0   - char[14]    - product
                15  - char[25]    - hospital name
                40  - char[12]    - patient number
                53  - char[22]    - patient name
                80  - char[2]     - date - dd
                83  - char[3]     - date - mmm
                87  - char[2]     - date - yy
                120 - char[2]     - time - hh
                123 - char[2]     - time - mm
                126 - char[2]     - time - ss
                156 - char[1]     - H=head first,F=feet first
                158 - char[2]     - SP=supine,PR=prone,
                                    RP=right lateral decubitus,
                                    LP=left lateral decubitus
                205 - char[4]     - slice number
                723 - char[4]     - scan time - secs
                763 - char[4]     - kv
                803 - char[4]     - dose - AmpS
                843 - char[4]     - slice thickness - mm
                883 - char[4]     - gantry tilt - degrees
                923 - char[4]     - table position - mm

                      If anyone knows what "EF2" and "35B" stand for I would
love to know - I presume they are something like the filter used, or field of
view or something ?

                      Also the DR family don't seem to be aware of the concept
of a hierarchy of examination/study and series numbering, which makes it
annoying to try to import them into PACS systems :( Correct me if I am wrong
but they just seem to keep bumping up the slice number for each patient as each
group of scans is done.

              3.2.2.2 Somatom Plus

                      Siemens version of SPI, containing the following private
data elements. Note that there is overlayed data in the high four bytes of the
image pixel data, and that there seems to be a bunch of padding in the middle.
The intent seems to be to store the "original header" and the image pixel data
at accessible, presumably standard locations, presumably indexed by the byte
offsets and lengths described in group 9. This is a shame because it seems that
none of the really interesting CT attributes have been included in the SPI
form, although SPI private tags are available for lots of CT parameters. I
don't have one of these image to test this theory, someone just sent me an
output of the attribute dump.

SPI private tags:

(0009,0010)                                      <SPI RELEASE 1>
(0009,0011)                                        <SIEMENS MED>
(0009,1011) SPI RELEASE 1   UID     <049S03CT031995011712072452>
(0009,1040) SPI RELEASE 1   DataObjectSubtype           [0x0000]
(0009,1041) SPI RELEASE 1   DataObjectSubtype         <IMA TOPO>
(0009,1110) SIEMENS MED     RecognitionCode             <CT 1.4>
(0009,1130) SIEMENS MED     ByteOffsetOfOriginalHeader
(0009,1131) SIEMENS MED     LengthOfOriginalHeader
(0009,1140) SIEMENS MED     ByteOffsetOfPixelmatrix
(0009,1141) SIEMENS MED     LengthOfPixelmatrixInBytes

(0011,0010)                                      <SPI RELEASE 1>

(0021,0010)                                        <SIEMENS MED>
(0021,1010) SIEMENS MED     Zoom                          <01.0>
(0021,1011) SIEMENS MED     Target              <000.000\00.000>
(0021,1012) SIEMENS MED     TubeAngle                     <0270>
(0021,1020) SIEMENS MED     ROIMask                     [0xf000]

Overlay descriptions (overlays already in image pixel data):

(6000,0040)                 ROI                              <G>
(6000,0102)                 BitPosition                 [0x000c]
(6000,0102)                 OverlayLocation             [0x7fe0]

(6002,0040)                 ROI                              <G>
(6002,0102)                 BitPosition                 [0x000d]
(6002,0102)                 OverlayLocation             [0x7fe0]

(6004,0040)                 ROI                              <G>
(6004,0102)                 BitPosition                 [0x000e]
(6004,0102)                 OverlayLocation             [0x7fe0]

(6006,0040)                 ROI                              <G>
(6006,0102)                 BitPosition                 [0x000f]
(6006,0102)                 OverlayLocation             [0x7fe0]

More SPI private stuff ... padding and original header ...

(7001,0010)                                        <SIEMENS MED>
(7001,1010) SIEMENS MED     Dummy

(7003,0010)                                        <SIEMENS MED>
(7003,1010) SIEMENS MED     Header

(7005,0010)                                        <SIEMENS MED>
(7005,1010) SIEMENS MED     Dummy

              3.2.2.3 Somatom AR

              Unknown, but likely to be SPI unless Siemens have second sourced
this machine like Philips does theirs from Hitachi or GE theirs from Yokogawa !

        3.2.3 Philips - Big black hole

        3.2.4 Picker

              Grey hole perhaps. This information probably pertains to the IQ
and PQ CT models, though I have no sample images to experiment with yet. I am
told that:

              - axial images are 512x512
              - pilot images are 1024x1024
              - uncompressed images are 12 bits stored in 16 bits
              - don't know how to handle compression scheme
              - raster order is as usual, by row, TLHC first
              - 8k header to be skipped

        3.2.5 Toshiba - another black hole
        3.2.6 Hitachi - another black hole
        3.2.7 Shimadzu - another black hole
        3.2.8 Elscint - another black hole

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.
Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01


    3.3 MR

        3.3.1 General Electric

              3.3.1.1 Signa 3X and 4X

                      3.3.1.1.1 Image data

                                - "fixed format" header
                                - image data is not compressed
                                - image data fixed offset 14336 bytes
                                - Data General host
                                - AOS/VS

                                The image files are of fixed layout, described
here as a series of 256 by 16 bit word blocks (512 bytes), blocks numbered from
0. The headers start at the following block offsets:

        block 0  - length 4 blocks   - System configuration
        block 4  - length 2 blocks   - Site customization
        block 6  - length 2 blocks   - Study header
        block 8  - length 2 blocks   - Series header
        block 10 - length 2 blocks   - Image header
        block 12 - length 4 blocks   - Raw database header
        block 16 - length 10 blocks  - Pulse sequence description
        block 26 - length 2 blocks   - Pixel map (? not ever used)
        block 28 - length 256 blocks - Image data

                                As decribed earlier, the header is a fixed
length of 14336 bytes, after which the uncompressed image data starts.

                                Some of the more important fields are described
here. Integers are 16 bit words (big-endian), ascii strings are Fortran style
specifications with length in bytes, and reals are 4 bytes long (see Host
machines - Data General), word offsets are numbered from 0:

        block 6 - study header

               word  32      - 5A   - Study number
               word  39      - 9A   - Date of study (dd-mmm-yy)
               word  47      - 8A   - Time of study (hh:mm:ss)
               word  54      - 32A  - Patient name
               word  70      - 12A  - Patient ID
               word  78      - 3A   - Age xxx years or xxD or W or M or Y
               word  80      - 1A   - Sex

        block 8 - series header

               word  31      - 3A   - Series number
               word  52      - 120A - Series description
               word  112     - Int  - Series type (0=normal,1=screensave,
                                          2=composite)
               word  113     - Int  - Coil type (0=head,1=body,2=surface)
               word  114     - 16A  - Coil name
               word  122     - Int  - Contrast description
               word  138     - Int  - Plane type (0=axial,1=sagittal,2=coronal,
                                          3=oblique,4=screen save)
               word  147     - Int  - Image mode (0=2D single,1=2D multiple,
                                          2=3D volume,3=cine,4=spectroscopy)
               word  148     - Int  - Field strength (gauss)
               word  149     - Int  - Pulse sequence (0=memp,1=ir,2=ps,3=rm,
                                          4=rmge,5=gre,6=vemp,7=mpgr,8=mpgrv,
                                          9=mpirs,10=mpiri,11=3d/gre,
                                          12=cine/gre,13=spgr,14=sspf,
                                          15=cin/spgr,16=3d/spgr,17=fse,
                                          18=fve,19=fspgr,20=fgr,21=fmpspgr,
                                          22=fmpgr,23=fmpir,24=probe.s,
                                          25=probe.p)
               word  150     - Int  - Pulse sequence subtype (0=chopper)
               word  151     - Real - Field of view mm
               word  153     - Real - Center (3 values;R+L-,A+P-,S+I-)
               word  159     - Int  - Orientation (0=supine,1=prone,2=Lt,3=Rt)
               word  160     - Int  - Position (0=head first,1=feet first)
               word  161     - 32A  - Longitudinal anatomical reference
               word  177     - 32A  - Vertical anatomical reference
               word  199     - Int  - Scan matrix X
               word  200     - Int  - Scan matrix Y
               word  201     - Int  - Image matrix

        block 10 - image header

               word  44      - Int  - Image number
               word  73      - Real - Image location
               word  75      - Real - Table position
               word  77      - Real - Image thickness
               word  79      - Real - Image spacing
               word  82      - Real - TR
               word  86      - Real - TE
               word  88      - Real - TI
               word  98      - Int  - Number of echos
               word  99      - Int  - Echo number
               word  101     - Int  - NEX (if not fractional)
               word  146     - Real - NEX
               word  146     - Int  - Flip angle

                      3.3.1.1.2 Tape format

                      3.3.1.1.3 Raw data

              3.3.1.2 Signa 5X - Genesis

                      General Electric now uses the same Sun based architecture
for its Advantage CT and Signa 5X MR family, referred to as Genesis. The
general details of this scheme will be discussed here, as well as the
description of the MR image header. Specifics related to the CT modality are
described elsewhere.

                      3.3.1.2.1 Image data

                                Genesis is a system running under SunOS 3.5G
(NOT Solaris) on, believe it or not, a sun3 68000 architecture, not a sun4
sparc.

                                It would appear that unlike in the previous
Data General based system, the active database is stored as one large
monolithic file in a raw partition, which doesn't make it very easy to extract
single imgaes. Fortunately, GE have saved the day by kindly providing, and
thoroughly documenting in the material that they send you when you ask for the
image file format, an Image Extract Tool that lives in "/usr/g/insite/bin" and
is called "ximg". To see what options are available just type "ximg -h" for
help. Note that ximg's default is to strip out the patient's name and ID number
which is annoying, so don't forget the "-s" flag. The default directory to put
the extracted images in is "/usr/g/insite/tmp". The input names to select
images in silent (non-menu) mode are of the following form:

                EeeeeeSsssIiii

                eeeee =  exam number   or "all"
                sss   =  series number or "all"
                iii   =  image number  or "all"

and the resultant filenames are the same with an extension of ".MR" or ".CT"
depending. For example:

                % /usr/g/insite/bin/ximg -i e673s1i1 -st
                % ls -l /usr/g/insite/tmp
                E673S1I1.MR

which extracts the selected image in silent mode (-i) without stripping the
identification (-s) in rectangular (-t) mode, ie. not compressed or packed.

                                One nifty feature that allows you to keep up to
date with the latest version header contents is the "-g" switch which invokes
the GenIncl utility that produces a file called "imageFileOffsets.h" that lists
the type and offsets of each field in the header ! Remarkable, huh ?

                                How does one get access to the operating system
on the Signa ? Let me count the ways. First, from the Advantage console one can
just call up a command shell from the Utilities menu, or one can invoke the Ftp
option uner Networks and then use the "!" command to ftp, which like in many
Unix tools, spawns a shell. Or from another workstation on the network one can
just telnet or rsh across. If you are connected using an Advantage Windows
workstation you can pull up a command shell by using the right menu button with
the cursor on the desktop. Doing a few "cat /etc/hosts" around the place will
let you know what all the machines are called.

One can also access the console directly from the plasma screen by toggling
"L1-B" on or off.

                                Once you have extracted them, the Genesis file
contains headers consisting of several components in common with CT and then a
specific CT or MR header. The file is structured as a "block type" header with
a brief "control header" of fixed size, followed by a bunch of optional
headers, some of which reflect internal database structures and are of no
interest, others (such as the suite/exam/series/image) headers that contain
descriptive and identification information, and two that are of importance for
deciphering the pixel data (unpack control & compression control). Some of the
more important fields are described here:

        Sun3 Data Types:

           - short is 16 bits
           - int is 32 bits
           - float is 32 bits IEEE
           - double is 64 bits IEEE
           - byte offsets from 0 start of file
           - length ==0 means header absent/empty

        control header (offset 0):

                0   - int      - magic number = 0x494d4746 = "IMGF"
                4   - int      - byte displacement to pixel data
                8   - int      - width
                12  - int      - height
                16  - int      - depth (bits)
                20  - int      - compression (0=asis,1=rectangular,2=packed,
                                 3=compressed,4=compressed&packed)
                32  - int      - background shade to use for non-image
                54  - u_short  - 16 bit end_around_carry sum of pixels
                56  - int      - ptr to unique image identifier
                60  - int      - length of unique image identifier
                64  - int      - ptr to unpack header
                68  - int      - length of unpack header
                72  - int      - ptr to compression header
                76  - int      - length of compression header
                80  - int      - ptr to histogram header
                84  - int      - length of histogram header
                88  - int      - ptr to text plane
                92  - int      - length of text plane
                96  - int      - ptr to graphics plane
                100 - int      - length of graphics plane
                104 - int      - ptr to data base header
                108 - int      - length of data base header
                112 - int      - value to add to stored pixels
                116 - int      - ptr to user defined data
                120 - int      - length of user defined data
                124 - int      - ptr to suite header
                128 - int      - length of suite header
                132 - int      - ptr to exam header
                136 - int      - length of exam header
                140 - int      - ptr to series header
                144 - int      - length of series header
                148 - int      - ptr to image header
                152 - int      - length of image header

        unpack header:

                // used when compression is packed, or compressed & packed
                // contains perimeter encoding map ... cf. GE 9800

                struct {
                        short pixels_to_left_of_line;
                        short pixels_in_stored_line;
                } table [height_of_image];

        compression header:

                Not necessary for decompressing entire image ... rather it
                contains seeds for various "strips" of the image to allow
                jumping into the compressed pixel data ... see the GE docs.

        histogram header:

                Contains statistical information for determining optimum
                windowing ... see the GE docs and GenIncl produced header

        exam header:

                0   - char[4]  - suite ID
                8   - u_short  - exam number
                84  - char[13] - patient ID
                97  - char[25] - patient name
                122 - short    - patient age
                126 - short    - patient sex
                305 - char[3]  - exam type - "MR" or "CT"

        series header:

                10  - short    - series number
                84  - char[3]  - anatomical reference
                92  - char[25] - scan protocol name

        image header - for MR (1022 bytes long):

                12  - short    - image number
                26  - float    - slice thickness mm
                30  - short    - matrix size - X
                32  - short    - matrix size - Y
                34  - float    - display field of view - X (mm)
                38  - float    - display field of view - Y (mm)
                42  - float    - image dimension - X
                46  - float    - image dimension - Y
                50  - float    - pixel size - X
                54  - float    - pixel size - Y
                72  - char[17] - iv contrast agent
                89  - char[17] - oral contrast agent
                194 - int      - repetition time(usec)
                198 - int      - inversion time(usec)
                202 - int      - echo time(usec)
                210 - short    - number of echoes
                212 - short    - echo number
                218 - float    - NEX
                308 - char[33] - pulse sequence name
                362 - char[17] - coil name
                640 - short    - ETL for FSE

                                So much for the headers. Now how does one deal
with the image data ? The easiest way of course is to save it as "rectangular",
that is not compressed and not packed. If you want to do it the hard way, then
if the data is packed, then unpack it, then if it is compressed, uncompress it.
The packing is a perimeter encoding method like the CT 9800, except that
instead of using a map containing just the width of the stored data, both a
left offset and a width are stored for each row, as described in the "unpack
header". The compression scheme is DPCM again but with a difference ... three
alternative encodings are possible ... a 7 bit difference (one byte), a 14 bit
difference (two bytes), or a flag byte followed by a true 16 bit pixel value
(three bytes). Presumably this scheme was devised to handle a greater dynamic
range than in the CT 9800 scheme when necessary, but produce a similar degree
of compression otherwise.

             0  +/- <------ 6 bits ------->
            _______________ _______________
           |   |   |   |   |   |   |   |   |
           |_______________|_______________|
             7           4   3           0

    or

             1   0  +/- <------------------ 13 bits ---------------------->
            _______________ _______________ _______________ _______________
           |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
           |_______________|_______________|_______________|_______________|
            15           12 11           8   7           4   3           0

    or

             1   1  <----- discarded ----->  Then two bytes for 16 bit word
            _______________ _______________
           |   |   |   |   |   |   |   |   |
           |_______________|_______________|
             7           4   3           0

                                  The following piece of C++ code pulled out of
a Genesis to DICOM translator will give you the general idea. Note that the
perimeter encoding map has already been read in (map_left and map_wide). Note
in particular the need to deal with sign extension of the difference values.
Unlike the CT 9800 example earlier, one has to use a separate loop for the
compressed data stream as all 16 bits are potentially in use.

static void
copygenesisimage(ifstream& instream,DC3ofstream& outstream,
    Uint16 width,Uint16 height,Uint16 depth,Uint16 compress,
    Uint16 *map_left,Uint16 *map_wide)
{
    unsigned row;
    Int16 last_pixel=0;
    for (row=0; row<height; ++row) {
        unsigned j;
        unsigned start;
        unsigned end;

        if (compress == 2 || compress == 4) { // packed/compacked
            start=map_left[row];
            end=start+map_wide[row];
        }
        else {
            start=0;
            end=width;
        }
        // Pad the first "empty" part of the line ...
        for (j=0; j<start; j++) outstream.write16(0);

        if (compress == 3 || compress == 4) { // compressed/compacked
            while (start<end) {
                unsigned char byte;
                instream.read(&byte,1);
                if (!instream) return;
                if (byte & 0x80) {
                    unsigned char byte2;
                    instream.read(&byte2,1);
                    if (!instream) return;
                    if (byte & 0x40) {    // next word
                        instream.read(&byte,1);
                        if (!instream) return;
                        last_pixel=
                            (((Uint16)byte2<<8)+byte);
                    }
                    else {            // 14 bit delta
                        if (byte & 0x20) byte|=0xe0;
                        else byte&=0x1f;
                        last_pixel+=
                            (((Int16)byte<<8)+byte2);
                    }
                }
                else {                // 7 bit delta
                    if (byte & 0x40) byte|=0xc0;
                    last_pixel+=(signed char)byte;
                }
                outstream.write16((Uint16)last_pixel);
                ++start;
            }
        }
        else {
            while (start<end) {
                Uint16 u=readUint16(instream);
                if (!instream) return;
                outstream.write16(u);
                ++start;
            }
        }

        // Pad the last "empty" part of the line ...
        for (j=end; j<width; j++) outstream.write16(0);
    }
}

                      3.3.1.2.2 Archive format

                                GE supply both DAT tape and 5.25" write once
and rewriteable optical disk drives.

                                The optical drives are made by Pioneer (bad
choice GE ... media format is incompatible with any other vendor so you need a
Pioneer DEC 702 drive to read it) and furthermore GE have never documented the
media format. The WORM is described as a short term solution that was intended
to be replaced by the rewritable system (tell that to existing WORM only
owners) and hence no documentation was produced. Why the rewriteable optical
formats are not documented is not clear to me but they aren't available, at
least not according to those I have asked.

                                Studying a Genesis system in operation it would
seem that neither type of optical disk is mounted as a regular file system (not
surprising for a WORM), and presumably the archive processes write directly to
the raw drives. I jave not encountered anyone yet who has successfully read and
deciphered this format but watch this space as I know one person who is trying.

                                As far as the DAT format is concerned, this
format is available though I don't have it (yet). Examining a tape reveals the
following however:

        - One file used as a tape label (single 8192 byte record)
        - Tape mark
        - Series of image files separated by tape marks

                                There does not seem to be a tape directory per
se.

                                Each image file is a modification of the format
created by the ximg utility to extract images from the database.

                                The ximg format is described as a file header
beginning with the magic number "IMGF" and then a short header that contains
byte offsets to the image data, and various suite, exam, series and image
headers.

                                The DAT images are NOT organized like this, but
do use exactly the same headers and image data layout (and compression
schemes). The difference is in the order of the header.

                                The first record of the file is 3180 bytes long
and contains:

        0-113      suite  header   (length 114)
        114-1137   exam   header   (length 1024)
        1138-2157  series header   (length 1020)
        2158-3079  image  header   (length 1022 for mr)
                                   (length 1020 for ct)
        3080-3179  zero padding

                                NB. this record DOES NOT begin with "IMGF" !

                                The second record of the file is 5208 bytes
long (in my case anyway) and followed by 8192 byte records and a final record
of whatever is left over.

                                This 5208 byte record contains a "proper"
header in the ximg output format and starts with "IMGF". The subsequent byte
offsets to the image data, compression headers, histogram header etc. are
correct and offset from the beginning of this second record and NOT the start
of the file. Furthermore the pointers to those headers in the first record
(suite, exam, series and image headers) are TOTALLY WRONG and must be ignored
... I don't know how their values are derived but it is not obvious.

                                I presume that the files were reorganized this
way in order to make it easy for simple utilities to access the demographic
data to index the tape or something. Anyway it is easy to rewrite utilities
that read the ximg format to take all this into account and extract the tags
and the
images.

                                The image data byte offset (eg. 5204) in the
file header is 4 bytes too short, eg. 3180 + 5204 + 4 -> 3188 which is where
the image data starts.

                                If you are not familiar with the Genesis ximg
format, on a Signa at least, you can run "/usr/g/insite/bin/ximg -g" to extract
a prototype C header file describing the file format.

                      3.3.1.2.3 Raw data

              3.3.1.3 Vectra

                      Same comments as pertain to the Sytec/Pace entry in the
CT section. A few sample files on a floppy would be much appreciated.

        3.3.2 Siemens

              3.3.2.1 GBS II

                      - it is NOT in SPI format
                      - seems to be fixed format
                      - files 133120 bytes
                      - image pixel data 256*256*2 little endian
                      - image pixel offset 4096 bytes

              3.3.2.2 SP

                      - it IS in SPI format (Release 1)
                      - ACR/NEMA data stream starts immediately
                      - big-endian byte order
                      - lots of private groups containing SPI & MR specific
                        tags, but much useful information in standard tags
                      - 12 bit allocated data in 16 bits stored, high bit 11
                      - after ACR/NEMA data, trailing garbage

                      Similar story as for the Somatom Plus. Siemens version of
SPI, containing the following private data elements. Note that there is
overlayed data in the high four bytes of the image pixel data, and that there
seems to be a bunch of padding in the middle. The intent seems to be to store
the "original header" and the image pixel data at accessible, presumably
standard locations, presumably indexed by the byte offsets and lengths
described in group 9. This is a shame because it seems that none of the really
interesting MR attributes have been included in the SPI form, although SPI
private tags are available for lots of MR parameters. This is in contrast to
the Impact which contains more interesting SPI tags.

SPI private tags:

(0009,0010)                                      <SPI RELEASE 1>
(0009,0011)                                        <SIEMENS MED>
(0009,1010) SPI RELEASE 1   Comments        <SPI VERSION  01.00>
(0009,1015) SPI RELEASE 1   UID     <000S00MR001994122719161248>
(0009,1110) SIEMENS MED     RecognitionCode             <MR 2.0>
(0009,1130) SIEMENS MED     ByteOffsetOfOriginalHeader   [0x800]
(0009,1131) SIEMENS MED     LengthOfOriginalHeader      [0x1600]
(0009,1140) SIEMENS MED     ByteOffsetOfPixelmatrix     [0x2000]
(0009,1141) SIEMENS MED     LengthOfPixelmatrixInBytes [0x20000]

(0011,0010)                                      <SPI RELEASE 1>

(0021,0010)                                        <SIEMENS MED>
(0021,1010) SIEMENS MED     Zoom                          <01.0>
(0021,1011) SIEMENS MED     Target                            <>
(0021,1020) SIEMENS MED     ROIMask                     [0x0000]

Overlay descriptions (overlays already in image pixel data):

(6000,0010)                 OverlayRows                 [0x0100]
(6000,0011)                 OverlayColumns              [0x0100]
(6000,0040)                 ROI                              <R>
(6000,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6000,0060)                 OverlayCompressionCode        <NONE>
(6000,0100)                 OverlayBitsAllocated        [0x0010]
(6000,0102)                 OverlayBitPosition          [0x000c]
(6000,0110)                 OverlayFormat                 <RECT>
(6000,0200)                 OverlayLocation             [0x7fe0]

(6002,0010)                 OverlayRows                 [0x0100]
(6002,0011)                 OverlayColumns              [0x0100]
(6002,0040)                 ROI                              <R>
(6002,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6002,0060)                 OverlayCompressionCode        <NONE>
(6002,0100)                 OverlayBitsAllocated        [0x0010]
(6002,0102)                 OverlayBitPosition          [0x000d]
(6002,0110)                 OverlayFormat                 <RECT>
(6002,0200)                 OverlayLocation             [0x7fe0]

(6004,0010)                 OverlayRows                 [0x0100]
(6004,0011)                 OverlayColumns              [0x0100]
(6004,0040)                 ROI                              <R>
(6004,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6004,0060)                 OverlayCompressionCode        <NONE>
(6004,0100)                 OverlayBitsAllocated        [0x0010]
(6004,0102)                 OverlayBitPosition          [0x000e]
(6004,0110)                 OverlayFormat                 <RECT>
(6004,0200)                 OverlayLocation             [0x7fe0]

(6006,0010)                 OverlayRows                 [0x0100]
(6006,0011)                 OverlayColumns              [0x0100]
(6006,0040)                 ROI                              <R>
(6006,0050)                 OverlayOrigin        [0x5c31,0x2031]
(6006,0060)                 OverlayCompressionCode        <NONE>
(6006,0100)                 OverlayBitsAllocated        [0x0010]
(6006,0102)                 OverlayBitPosition          [0x000f]
(6006,0110)                 OverlayFormat                 <RECT>
(6006,0200)                 OverlayLocation             [0x7fe0]

More SPI private stuff ... padding and original header ...

(7001,0010)                                        <SIEMENS MED>
(7001,1010) SIEMENS MED     Dummy

(7003,0010)                                        <SIEMENS MED>
(7003,1010) SIEMENS MED     Header

(7005,0010)                                        <SIEMENS MED>
(7005,1010) SIEMENS MED     Dummy

NB. Siemens VR for OverlayOrigin seems to be wrong. ACR/NEMA says it should be
binary, but [0x5c31,0x2031] translates to a string <1\1> which seems more
plausible!

                      The models in this family include the SP (which the SPI
describes as a GBS 3 !), the SP/4000 which got a faster Vax, and the new
Vision. I have only examined the files from the SP so far, but they are bog
standard SPI with no surprises, and I have no reason to doubt the same is true
of the later models.

                      The usual Vax VMS problems apply. Use the console serial
port on the back of the Vax. There is a C compiler supplied so you can compile
the more recent C version of kermit ... although the old Bliss version works
fine. Unlike the Philips, there is no problem with CR delimited file attributes
being set on the binary files. Kermit transfers are glacially slow as always.

              3.3.2.3 Impact

                      - it IS in SPI format (Release 1, based on ACR/NEMA 2.0)
                      - skip the 1st 128 bytes to get to ACR/NEMA data stream
                           (may be artifact of transfer process)
                      - big-endian byte order
                      - lots of private groups containing SPI & MR specific
                        tags, but much useful information in standard tags
                      - 12 bit allocated data in 16 bits stored, high bit 11
                      - after ACR/NEMA data, file is padded to 512 byte mark

                      Siemens version of SPI, containing the following private
data elements. More comprehensive attributes than the Somatom Plus or SP. There
is no overlayed data in the high four bytes of the image pixel data, and that
there is no padding in the middle or "original header", or byte offsets and
lengths described in group 9. Only some of the more significant elements are
described here in the interest of brevity. Sources for a more comprehensive
dictionary are described under SPI.

SPI private tags:

(0009,0010)                 PrivateCreator                <SPI RELEASE 1>
(0009,0012)                 PrivateCreator          <SIEMENS CM VA0  CMS>
(0009,0013)                 PrivateCreator          <SIEMENS CM VA0  LAB>
(0009,1010) SPI RELEASE 1   Comments                 <SPI VERSION  01.00>
(0009,1015) SPI RELEASE 1   UID              <000S00MR001994021614211710>
(0009,1040) SPI RELEASE 1   DataObjectSubtype                    [0x0000]
(0009,1041) SPI RELEASE 1   DataObjectSubtype                  <MRUPNONE>
(0009,1210) SIEMENS CM VA0  CMS  StorageMode                   <EXPANDED>
(0009,1212) SIEMENS CM VA0  CMS  EvaluationMask                  [0x0000]
(0009,1226) SIEMENS CM VA0  CMS  LastMoveDate                <1994.02.16>
(0009,1227) SIEMENS CM VA0  CMS  LastMoveTime              <13:41:52.000>
(0009,1320) SIEMENS CM VA0  LAB  HeaderVersion                      <VB6>

(0011,0011)                 PrivateCreator          <SIEMENS CM VA0  CMS>
(0011,1110) SIEMENS CM VA0  CMS RegistrationDate             <1994.02.16>
(0011,1111) SIEMENS CM VA0  CMS RegistrationTime          <113:43:49.000>
(0011,1123) SIEMENS CM VA0  CMS UsedPatientWeight                <000050>

(0019,0010)                 PrivateCreator          <SIEMENS CM VA0  CMS>
(0019,0012)                 PrivateCreator          <SIEMENS MR VA0  GEN>
(0019,0014)                 PrivateCreator         <SIEMENS MR VA0  COAD>
(0019,0015)                 PrivateCreator         <SIEMENS CM VA0  ACQU>
(0019,1060) SIEMENS CM VA0  CMS NumberOfDataBytes                <310127>
(0019,1220) SIEMENS MR VA0  GEN NominalNumberOfFourierLines      <000128>
(0019,1226) SIEMENS MR VA0  GEN NumberOfFourierLinesafterZero    <000063>
(0019,1228) SIEMENS MR VA0  GEN FirstMeasuredFourierLine         <-00064>
(0019,1230) SIEMENS MR VA0  GEN AcquisitionColumns               <000512>
(0019,1231) SIEMENS MR VA0  GEN ReconstructionColumns            <000512>
(0019,1250) SIEMENS MR VA0  GEN CurrentNumberOfAverages          <000010>
(0019,1260) SIEMENS MR VA0  GEN FlipAngle                <00.8000000+E00>
(0019,1290) SIEMENS MR VA0  GEN NumberOfSaturationRegions        <000000>
(0019,1294) SIEMENS MR VA0  GEN ImageRotationAngle       <00.0000000+E00>
(0019,1412) SIEMENS MR VA0  COAD MagneticFieldStrength   <009.500702E-01>
(0019,1456) SIEMENS MR VA0  COAD ReceiverFilterFrequency         <500000>

(0021,0010)                     PrivateCreator              <SIEMENS MED>
(0021,0011)                     PrivateCreator      <SIEMENS CM VA0  CMS>
(0021,0013)                     PrivateCreator      <SIEMENS MR VA0  GEN>
(0021,1010) SIEMENS MED Zoom                                           <>
(0021,1011) SIEMENS MED Target                                         <>
(0021,1020) SIEMENS MED ROIMask                                     [0x0]
(0021,1120) SIEMENS CM VA0  CMS FoV        <00.2050000+E200\.2050000+E20>
(0021,1122) SIEMENS CM VA0  CMS ImageMagnificationFactor <001.000000E+00>
(0021,1130) SIEMENS CM VA0  CMS ViewDirection                      <HEAD>
(0021,1132) SIEMENS CM VA0  CMS RestDirection                      <HEAD>
(0021,1160) SIEMENS CM VA0  CMS ImagePosition        <000.000000E+00\.\.>
(0021,1161) SIEMENS CM VA0  CMS ImageNormal          <-00.000000E+00\.\.>
(0021,1163) SIEMENS CM VA0  CMS ImageDistance            <002.787480E+01>
(0021,116a) SIEMENS CM VA0  CMS ImageRow             <001.000000E+00\.\.>
(0021,116b) SIEMENS CM VA0  CMS ImageColumn          <000.000000E+00\.\.>
(0021,1170) SIEMENS CM VA0  CMS PatientOrientationSet1          <R\AH\HP>
(0021,1171) SIEMENS CM VA0  CMS PatientOrientationSet2          <L\PF\FA>
(0021,1180) SIEMENS CM VA0  CMS StudyName    <routine_brain/6_opt3_mprag>
(0021,1182) SIEMENS CM VA0  CMS StudyType                           <MEA>
(0021,1334) SIEMENS MR VA0  GEN NumberOf3DImagePartitions        <000128>
(0021,1339) SIEMENS MR VA0  GEN SlabThickness            <001.800000E+02>
(0021,1342) SIEMENS MR VA0  GEN CurrentSliceNumber               <000001>
(0021,1343) SIEMENS MR VA0  GEN CurrentGroupNumber               <000001>
(0021,134f) SIEMENS MR VA0  GEN OrderofSlices                 <ASCENDING>
(0021,1370) SIEMENS MR VA0  GEN NumberOfEchoes                   <000001>

(0029,0011)                     PrivateCreator      <SIEMENS CM VA0  CMS>
(0029,1120) SIEMENS CM VA0  CMS PixelQualityCode         <NONE\NONE\NONE>

(0051,0010)                     PrivateCreator      <SIEMENS CM VA0  CMS>
(0051,1010) SIEMENS CM VA0  CMS ImageText                           <...>

              3.3.2.4 Vision

                      Unknown. Bound to be SPI but don't know what attributes
are present.

        3.3.3 Philips

              3.3.3.1 S5

                      - can export as ACR/NEMA (actually SPI) files
                      - little endian byte order
                      - 12 bit packed data

                      This description pertains to "exported ACR/NEMA", not the
native image files, which I am not familiar with. In fact I am not even sure in
which directory they live.

                      Use the ADMIN menu on the operator's console to find the
import/export ACR/NEMA utility, with which you can select an exam, series or
image to export as an ACR/NEMA file. The default directory is the GYROVIEW home
directory, which is already pretty cluttered so it is better to make another
subdirectory like "ANI" to keep exported files in. The exported files have huge
names composed of identification information, but all have a ".ANI" extension.
For example:

        DIR SYS$SYSROOT:[GYROSCAN]*.ANI;*

        SMITH__FA02010801010001.ANI;1

                      These files are stored as, wait for it, fixed length 512
byte records, with the "carriage return carriage control" record attributes set
from some bizarre reason, which totally messes up kermit which starts messing
with adding and changing CR/LF characters. See the Vax diatribe below for a
method of getting around this, by using DUMP as a poor man's uuencode
permitting ascii transfer. Unfortunately the nature of fixed length records
under VMS means that the last record will be padded out to 512 bytes without
any indication of the "real" end-of-file. This means your ACR/NEMA reader has
to cope with trailing garbage gracefully.

                      Unlike the Siemens SPI files, the Philips ones are stored
in little-endian format. There is no fixed size header to skip, just go
straight into the ACR/NEMA data stream. For the image pixel data four 12 bit
words are packed without padding into 16 bit words, without any compression
sheme. See the ACR/NEMA section for description of the packing organization.
Lots of private tags are defined, but these can be ignored. Some of the
identifying tags present are as follows:

(0000x8,000x10) CS RecognitionCode       VR=<CS>   VL=<0xc>  <ACR-NEMA 1.0>
(0000x8,000x70) LO Manufacturer          VR=<LO>   VL=<0x8>  <Philips >
(0000x8,0x1090) LO ManufacturerModelName VR=<LO>   VL=<0x2>  <S5>
(0000x9,000x10) LT SPIComments   VR=<LT>   VL=<0xe>   <SPI Release 1 >
(000x19,000x10)                  VR=<LT>   VL=<0x14>  <PHILIPS MR R5.6/PART>

                      To get the files off, I plug a portable with a serial
cable into one of the spare serial ports inside one of the Vax cabinets, at
9600 baud, and login as "GYROVIEW/NOCOM" without any password needed. This
dumps you in the same directory as the files will be stored by default. You
will probably need to set local echo on on your portable, or "SET
TERMINAL/ECHO" on the Vax.
Kermit was already loaded on my system, accessed as "RUN [SYSEXE]KERMIT". See
the Vax section later for more help.

              3.3.3.2 ACS
              3.3.3.3 T5
              3.3.3.4 NT5 & NT15

        3.3.4 Picker - another black hole
        3.3.5 Toshiba - another black hole
        3.3.6 Hitachi - another black hole
        3.3.7 Shimadzu - another black hole
        3.3.8 Elscint - another black hole

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.
Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01


    3.4 Proprietary Workstations

        3.4.1 ISG

              3.4.1.1 Gyroview

                      The Philips Gyroview workstation is a high-resolution
graphical workstation for MR images from Gyroscan scanners, that can also
handle CT images and other modalities, and has an optional package for three
dimensional processing of images. It is based on a Sun SPARC system with
proprietary graphics hardware. The software is actually written by ISG in
Canada. The image format is an ACR/NEMA based format with various private tags
defined, and a proprietary scheme of image compression that has me stumped. I
am told by some that there is no means of telling the Gyroview not to compress
the images. I use compress in the sense that includes packing four 12 bit words
into three 16 bit big-endian words, which appears to be part of the scheme in
use. Unfortunately, some form of perimeter encoding is also in use, and I just
can't figure it out :( Some people have had more luck using "the export utility
of the Gyroview" to produce just 12 bit packed images without the perimeter
encoding. I don't know whether this is a standard feature of the workstation or
not. Others have suggested looking in the "/isg/3dmr/DataRoot/tscript/"
directory for hints.

                      Despite prolonged exchanges of email, and encouragement
from other individuals at ISG, it seems that the formal decision by the manager
of the customer service department, Irene Gearin, is not to release the format.
Customers may contact her at [e-mail] for information on how to obtain
a software package called the External Developers Tool which contains a tool
called xdimage which can only be used on ISG's proprietary hardware. Whether
this is free to customers or costs extra I am not sure, but I believe a
non-disclosure agreement is required.

                      I would still prefer to know the format, as people keep
asking (these machines were pretty popular I gather), and if anyone has any
hints about the data format, I would appreciate them. Here follows part of a
reply to one of these people when I made an unsuccesful attempt to figure this
out:

Firstly, I presume this file is generated by a Philips Gyroview workstation
judging by ...

(0008,0070) LO Manufacturer  VR=<LO>  VL=<8>  <GYROVIEW>

The file says it is an MRI image ...

(0008,0060) CS Modality  VR=<CS>  VL=<2>  <MR>

and yet it is missing many of the mri attributes normally present. Also it
includes some CT specific attributes, notably ...

(0018,1120) DS GantryDetectorTilt  VR=<DS>  VL=<2>  < 0>

which is pretty weird. I presume that this format is generated by something
purely for the purposes of 3D reconstruction and only the attributes needed for
that have been preserved.

The image appears to be 512*512 ...

(0028,0010) US Rows     VR=<US>  VL=<2>  [200]
(0028,0011) US Columns  VR=<US>  VL=<2>  [200]

As far as the compression format is concerned ...

(0028,0060) CS CompressionCode  VR=<CS>  VL=<2>  < 2>

is not in itself a valid ACR/NEMA value, and hence some proprietary variation
is in use. The most important clue is ...

(0028,0040) CS ImageFormat  VR=<CS>  VL=<4>  <CIRC>

which is also not valid ACR/NEMA (only RECT is permitted). From this I conclude
that some sort of 'circular' perimeter encoding scheme is in use that only
sends the meaningful central pixels in each row and leaves out the background.
This is substantiated by the fact that the image pixel data seems to be
preceded by a table of 257 long words in ascending order, each value separated
by relatively low values (80-100 or so). I suspect that these are pointers into
the data to the start of each row...

% od -x I011_1_001 +1404 | more
0001404  0000 0202 0000 0252 0000 02a2 0000 02f2
0001424  0000 0342 0000 0392 0000 03e2 0000 0432
0001444  0000 0482 0000 04d2 0000 0522 0000 0572
0001464  0000 05c2 0000 0612 0000 0662 0000 06b3
0001504  0000 0705 0000 0757 0000 07ab 0000 0800
0001524  0000 0857 0000 08ae 0000 0905 0000 095e ...

[0000] 000514 -> 000514
[0001] 000594 -> 000080
[0002] 000674 -> 000080
[0003] 000754 -> 000080
[0004] 000834 -> 000080
[0005] 000914 -> 000080

 ...

[0155] 015322 -> 000103
[0156] 015425 -> 000103
[0157] 015527 -> 000102
[0158] 015629 -> 000102

 ...

[0254] 024484 -> 000080
[0255] 024564 -> 000080
[0256] 024564 -> 000000

The first of these values seems to be a pointer in two byte word units past the
table, the entries for a series of rows, then a final "257th" value that is the
same as the preceding with a difference of zero, possibly flagging the end of
the table.

What confuses me is the fact that there are 256 or so entries rather than 512
(number of rows), and that the difference values are relatively small for 512
columns. Perhaps each entry applies to two successive rows though this seems
rather peculiar.

Furthermore, if it is true that the units are two byte words, then the last
pointer value is much lower than the number of remaining bytes in the image
pixel data attribute, so what are all the other bytes for ?

The other thing that is going to make extraction difficult is the fact that the
data are supposed to be 12 bits packed into 16 bit words ...

(0028,0100) US BitsAllocated  VR=<US>  VL=<2>  [c]
(0028,0101) US BitsStored     VR=<US>  VL=<2>  [c]
(0028,0102) US HighBit        VR=<US>  VL=<2>  [b]

Hence 3 two byte words are used to store 4 12 bit pixels. It may not be easy to
figure out in what order this packing is performed. The ACR/NEMA standard has
an example of its intent in this case, but the byte order was never specified
for this standard, which had a 16 bit hardware data path and was not originally
intended for offline data storage in bytes, so there are a number of possible
permutations to deal with :(

Finally I don't know what to make of the "private" tags ...

Unrecognized (0029,0010)  VR=<LT>  VL=<a> <ISG shadow>
Unrecognized (0029,1070)  VR=<LT>  VL=<6> < 49128>
Unrecognized (0029,1080)  VR=<LT>  VL=<6> <123432>
Unrecognized (0029,1090)  VR=<LT>  VL=<2> < 0>

which presumably have some significance or they wouldn't be there !

    3.5 Other

         Empty at present.

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.
Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01


4.  Host Machines

    4.1 Data General

        4.1.1 Data

              4.1.1.1 Integers

                      Integers are 16 bit two's complement and stored in
big-endian format as on Sun Sparc and opposite to the Dec VAX.

              4.1.1.2 Floating Point

                      Single precision real values are 32 bits long, in
big-endian format. The high bit is the sign bit, followed by a 7 bit excess 64
exponent (power to which 16 must be raised) then a 24 bit hexadecimally
normalized mantissa with the decimal point to the left of the most significant
bit. Double precision values just have another 32 bits tacked on the mantissa
and the same exponent format.

            Sign
           |<-->|<------ Exponent ------>|<--------- Mantissa -------->|
            ______________ ______________ ______________ ______________
           |              |              |              |              |
           |______________|______________|______________|______________|
            31          28 27          24 23          20 19          16
           |<----------------------- Mantissa ------------------------>|
            ______________ ______________ ______________ ______________
           |              |              |              |              |
           |______________|______________|______________|______________|
            15          12 11           8 7            4 3            0

                      Here is a little piece of C++ code that should run on
anything and convert Data General floats to whatever the host's floating point
format is.

        double    value;
        unsigned char    sign;
        Uint16        exponent;
        Uint32        mantissa;

        typedef struct {
            unsigned    sign : 1;
            unsigned    exponent : 7;
            unsigned    mantissa : 24;
        } DG_FLOAT;

        DG_FLOAT number;

        unsigned char buffer[4];
        instream.read(buffer,4);
        if (instream) {
            // DataGeneral is a Big Endian machine
            memcpy ((char *)(&number),buffer,4);
            sign     = number.sign;
            exponent = number.exponent;
            mantissa = number.mantissa;

            value = (double) mantissa / (1 << 24) *
                pow (16.0, (long)(exponent) - 64);
            value = (sign == 0) ? value : -value;
        }
        else {
            cerr << "read failed\n" << flush;
            value=0;
        }

        4.1.2 Operating System

              4.1.2.1 RDOS

                      Used on the GE CT 9800 family. Severely primitive but
then is running on an old machine that can only map 64Kb of memory at a time
after all. It is apparently multitasking. Documentation may still be available
from Data General (try DG Direct) but is not supplied with the scanner by GE.
If anyone knows where I can find it at a reasonable price let me know. Here is
a brief command summary culled from a nifty pocket book from GE for
SunOS/Genesis users that compares commands:

                 CHATR  - file attributes
                 CRAND  - create randomly organized file
                 CDIR   - create directory
                 DELETE - files or directories
                 DIR    - change directory
                 DISK   - free space
                 FILCOM - compare files
                 GDIR   - show working directory name
                 GTOD   - show date and time
                 LINK   - files (symbolic)
                 LIST   - directory contents
                 MOVE   - a file
                 RENAME - a file
                 SDAT   - set date
                 STOD   - set time
                 SDUMP  - write files to a device
                 SLOAD  - read dumped files
                 SPEED  - tex editor
                 TYPE   - contents of file
                 XFER   - copy a file

                 wildcards: '-' is series, '*' is single character

              4.1.2.2 AOS/VS

                      Used on the GE Signa 3X and 4X family. Quite a nice
operating system with multi-tasking and hierarchical directories. Here is a
brief command summary again culled from a nifty pocket book from GE for
SunOS/Genesis users that compares commands:

                 ACL         - access control list (ownership)
                 BYE         - exit command process
                 COPY        - a file
                 CREATE      - a text file
                 CREATE/DIR  - a directory
                 CREATE/LINK - link files
                 DELETE      - files & directories
                 DIR         - display or change working directory
                 DUMP        - to peripheral
                 F/AS/S      - directory listing with file status
                 DATE        - show or set
                 HELP
                 LOAD        - DUMPed files
                 MOVE        - a file
                 RENAME      - a file
                 PATH        - show pathname of a file
                 PAUSE       - the command line interpreter
                 SUPERU ON   - enable superuser
                 SED         - text editor
                 TIME        - show or set
                 TYPE        - contents of text file
                 ?           - list processes running

                 wildcards: '+' is series, '*' is single character

                      Other useful hints include the use of "^" to refer to the
next directory up (like ".." in Unix) in DIR commands. Command options follow
the command name without any spaces and are indicated by a slash. COPY
operations specify the destination name first and then the source name. Devices
like the mag tape are indicated by "@", for example "@MTB0" is tape drive zero.
Files on the tape can be referred to as "@MTB0:nn" which is very handy. For
example to read a file off a CT 9800 tape under AOS/VS:

                COPY/V/IMTRSIZE=8192 B038040101.YP @MTB0:18

                      Perhaps most importantly, there is an extensive online
help system ... use the HELP command.

        4.1.3 Network

              If you have a GE Signa based on a DG then you can get the
so-called "High Speed Network" card and software from GE. From memory it is
pretty pricey, and there used to be a "slower" network interface that was
cheaper, but I don't think this is available anymore.

              If you have a CT 9800 based on the DG S/140 and you need to get
it connected there are a number of solutions:

             - Talk to GE about there ID/LINK II product ... I gather this is a
device that hooks into the SCSI cable to the hard drive (you need one of the
Ace drives not the old Zebra drive), monitors disk activity and snatches pieces
of the conversation to make a copy of the image data, stores it and makes it
available via some network protocol. Sound crazy ? Perhaps, but they tell me it
works and the price is reasonable, at least for something from GE anyway. Get
them to throw one in next time you buy something big.

             - The do-it-yourself approach. Talk to John Clayton
([e-mail]) at Claflin and Clayton. They supply a complete R-level
solution by providing Ethernet hardware and TCP/IP software for 16 bit DG OS
including AOS and RDOS (specifically including the GE CT version of RDOS). He
tells me "you can expect a file transfer rate of 25 kbytes/s for S/140
systems". The package consists of:

              $2,850 - EC-10 ethernet controller
              $1,645 - RDOS TCP/IP software (telnet client,ftp client/server)

              I have not personally tried either of these approaches, and I am
sure there are others (talk to Merge or DeJarnette), but I am getting really
tired of carrying 9-track tapes around so perhaps I will bite the bullet soon
(and upgrade to a HighSpeed Advantage !).

    4.2 Vax

        4.2.1 Data

              4.2.1.1 Integers

                      - little endian
                      - 8, 16, or 32 bits

              4.2.1.2 Floating Point

                      - little endian
                      - D_float

                        - 8 bytes
                        - sign bit 15
                        - exponent bits 14-7 excess 128 binary
                        - fraction MSB firstbits 6-0, 31-16, 47-32, 63-48
                        - normalized bit is not represented (hidden)

                      - G_float

                        - 8 bytes
                        - like D, but
                        - exponent is bits 14-4 excess 1024
                        - fraction 3-0 and 63-16

                      - F_float

                        - 4 bytes
                        - like D, smaller fraction

                      - H_float

                        - 16 bytes
                        - like G, but
                        - exponent is bits 14-0 excess 16384
                        - fraction is bits 127-16

                          - same wierd order
                          - bit 112 least significant

              4.2.1.3 Strings

                      - 16 bits of length
                      - byte of type
                      - byte of class
                      - 32 bits of pointer

        4.2.2 Operating System

              4.2.2.1 VMS

                      Truely one of the world's most irritating operating
systems to use, especially if you are a unix fan. Still it works, has a great
online help system that saves one's butt almost often enough to be useful, and
if you can remember the directory where kermit is stored and the weird command
to invoke it one can get by (barely).

                      If you don't know VMS and the vendor doesn't supply the
manuals, get them from DEC ... you need them bad ... real bad. If (like me) you
throw them out everytime you move then encounter another piece of archaic
equipment, you need the "vaxbook" which is available via ftp from
decoy.uoregon.edu, written by Joseph E St Sauver, which summarizes commands,
files and all sorts of application specific stuff, though it is no substitute
for the real thing.

                      Recent VMS update: goddamn file formats ! Why can't VMS
behave like a real operating system and forget this file format crap ! I have
some Philips S5 MR images exported in ACR/NEMA format and I can't get the
things off the hosts's Vax using Kermit, because though they have fixed length
512 byte records, some cretinous program sets the "carriage return carriage
control" record attributes, which causes kermit to send with all the '0A'
characters scrubbed out amongst other atrocities. I am getting desperate and
about to try using the Hex/Dehex utility that came with Kermit to get the stuff
off and then decode the hex format ! Or perhaps even use "dump" to make a
textfile, transfer, and decipher that. (No I don't have a C compiler for the
Vax so I guess I can't use uuencode unless someone wants to mail me a hex'ed
executable). Any hints, or instructions as to how to use FDL and Convert, to
change it to a normal format would be appreciated. (Why can't they just have a
"set file record attribute xxx" command like all the other millions of set
commands ? Grrrr.).

                      More recent VMS update: finally had an inspiration while
staring at hex dumps of these files - why not use the VMS "DUMP" utility which
produces hex dumps as a "poor man's uuencode" by saving the dump to a file,
transferring it as an ascii file, and then decoding it at the destination ? Of
course there are no nifty line checksums or anything, but a transfer protocol
such as kermit takes care of this. The DUMP output defaults to 8 32 bit long
words separated by a space per line displayed as hex, then an ascii string (32
bytes) and then a 24 bit word hex address offset from the start of the fixed
length record. All the data containing lines start with a single space, where
as descriptions at the start of each record begin in the first column, hence
the data lines can be easily selected out. By the way, the hex version of the
data is listed in reverse order ! VMS is so bizarre ! For example, here is a
fixed length 512 byte record file from a Philips S5 MRI (some of the hex words
elided to make the line fit on the page):

Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ...
File ID (2419,301,0)   End of file block 198 / Allocated 200

Virtual block number 1 (00000001), 512 (0200) bytes

 0000000C 00100008 ... 00000008 ........|...........=........... 000000
 00083932 2E36302E ... 2D524341 ACR-NEMA 1.0.. .....1994.06.29.. 000020
 00600008 4D5F4553 ... 00000030 0.......@.........A.....SE_M..`. 000040
 494B0000 00100080 ... 00000002 ....MR..p.....Philips ........KI 000060

 00183148 00000002 ... 32200000 .. 2........63865375........H1.. 0001E0
^L
Dump of file SYS$SYSROOT:[GYROSCAN]ABAALKHAIL02010201010001.ANI;1 ...
File ID (2419,301,0)   End of file block 198 / Allocated 200

Virtual block number 2 (00000002), 512 (0200) bytes

 40000018 45424F52 ... 00161250 P.....AGACQ_PT_SURFACE_PROBE...@ 000000

And so on ... you get the idea. This ugly little C++ utility written quickly
during this moment of inspiration will take saved DUMP output and make it
binary again:

#include <fstream.h>

#include "MainCmd.h"

signed char
hextobin(char c)
{
    signed char r;
    switch (c) {
        case '0':    r=0; break;
                case '1':       r=1; break;
                case '2':       r=2; break;
                case '3':       r=3; break;
                case '4':       r=4; break;
                case '5':       r=5; break;
                case '6':       r=6; break;
                case '7':       r=7; break;
                case '8':       r=8; break;
                case '9':       r=9; break;
        case 'A':
                case 'a':       r=0xa; break;
                case 'B':
        case 'b':       r=0xb; break;
                case 'C':
        case 'c':       r=0xc; break;
                case 'D':
        case 'd':       r=0xd; break;
                case 'E':
        case 'e':       r=0xe; break;
                case 'F':
        case 'f':       r=0xf; break;
        default:    r=-1; break;
    }
    return r;
}

int
main(int argc,char **argv)
{
    CCOMMAND(argc,argv);

    while (1) {
        const linemax=132;        // only needs 113
        char line[linemax];
        cin.getline(line,linemax);
        if (!cin || cin.eof()) {
            // cerr << "Bad or eof\n" << flush;
            break;
        }
        unsigned count=cin.gcount();
        if (count == 0 || line[0] != ' ') continue;
        if (count != 113) {
            cerr << "Line length " << count << "\n" << flush;
            break;
        }
        unsigned i;
        char *ptr = line + 8*(1+8);
        // line is in reverse order ...
        for (i=0; i<8; ++i) {
            unsigned j;
            for (j=0; j<4; ++j) {
                // 2 hex bytes -> 1 byte
                char bytelo = *--ptr;
                char bytehi = *--ptr;
                unsigned char byte
                    = (hextobin(bytehi)<<4)
                      + hextobin(bytelo);
                cout.put(byte);
            }
            --ptr;    // space between long words
        }
    }
    return 0;
}

                      Note that the nature of fixed length records under VMS
means that the last record will be padded out to 512 bytes without any
indication of the "real" end-of-file. This means you have to cope with trailing
garbage gracefully.

                      Hot VMS/Philips news: [e-mail] (Peter
Neelin) tells me there is an extremely useful tool for fiddling binary files
called FILE from DECUS. It allows you to change a file's header information
without modifying the content of the file. This then permits ftp, kermit, etc.
to do the right thing with Philips .ANI files. It also permits wildcards and
does not make a copy of the file (so it is fast). He says also that someone has
told him that they succeeded in using convert to fix these files, but his
general experience with it is not positive (it will often change the content of
the file and it doesn't allow wildcards, in addition to promoting the use of
the horrible fdl editor!). If you are interested, you can get FILE through
gopher from decus.org (look for the DECUS software library archives, under
essential tools). The binary is provided in case you don't have a compiler.

                      Some other useful hints:

                      - To log onto a serial terminal without executing the
login command file add "/NOCOM" to the username ... this way you can use the
operator console login which often won't require a password.

                      - There is a kermit available for the Vax under VMS (file
prefix "vms" in area or tape b) ... I use the "obsolete" version written in
Bliss, because it comes from the archives at columbia with a hex encoded
executable which can be uploaded just using an ordinary text capture into a
file, and doing the same with the short Macro hex program that can then be
assembled and used to make the convert into the real executable. Look in places
like [SYSEXE] first though to be sure Kermit is not already there. The generic
C version of kermit runs under VMS (file prefix "ck" in area or tape f), but
not every imaging machine comes with a VMS C compiler, whereas Macro is always
supposed to be there I gather. There is however also a hex encoded executable
of the C version in the archives (ckvker.hex) which I haven't tried, and is the
one that is recommended in the kermit documentation.

                      - There is apparently a zmodem for VMS but I don't know
where it comes from or how to get it.

                      - Serial ports are almost always defaulted to 9600 baud.

                      - "SET TERMINAL/ECHO" often isn't set.

              - Vax/VMS ftp conventions:

            UNIX FTP server     Vax/VMS FTP server

            cd dir                cd [.dir]
            cd dir/subdir         cd [.dir.subdir]
            cd ..                 cd [-]

              4.2.2.2 ULTRIX
              4.2.2.3 OSF

    4.3 Sun - Sun3 68000 and Sun4 Sparc

        4.3.1 Data

              The sun3 and sun4 architectures use much the same formats. Even
though the processors are different both are big-endian and the float formats
are IEEE. See the Sparc Architecture Manual - Chapter 3 - Data Formats for more
details.
              4.3.1.1 Integers

                      Integers are 8, 16, 32, or 64 bit unsigned or signed
two's complement and stored in big-endian format as on Data General and
opposite to the Dec VAX. Most C compilers treat short as 16 bits, and int and
long as 32 bits.

              4.3.1.2 Floating Point

                      Formats conform to IEEE 754-1985. Single precision real
values are 32 bits long, in big-endian format. The high bit is the sign bit,
followed by a 8 bit excess 127 exponent (power to which 2 must be raised) then
a 23 bit normalized mantissa with the decimal point to the left of the most
significant bit, from which 1.0 has been subtracted. Double precision values
have a 11 bit excess 1023 exponent and a 52 bit mantissa. Quad precision values
have a 15 bit excess 16383 exponent and a 112 bit mantissa.

            Sign
           |<-->|<-------- Exponent -------->|<------- Mantissa ------>|
            ______________ ______________ ______________ ______________
           |              |              |              |              |
           |______________|______________|______________|______________|
            31          28 27          24 23          20 19          16
           |<----------------------- Mantissa ------------------------>|
            ______________ ______________ ______________ ______________
           |              |              |              |              |
           |______________|______________|______________|______________|
            15          12 11           8 7            4 3            0

                      Here is a little piece of C++ code that should run on
anything and convert Sun IEEE floats to whatever the host's floating point
format is. It probably should take into account a few special cases to be
strictly correct:

        unsigned char buffer[4];
        instream.read(buffer,4);
        if (instream) {
#ifdef USESUN4NATIVEFLOAT
            float fvalue;
            memcpy ((char *)(&fvalue),buffer,4);
            value=fvalue;
#else  USESUN4NATIVEFLOAT
            unsigned char    sign;
            Uint16        exponent;
            Uint32        mantissa;

            typedef struct {
                unsigned    sign : 1;
                unsigned    exponent : 8;
                unsigned    mantissa : 23;
            } IEEE_FLOAT_SINGLE;

            IEEE_FLOAT_SINGLE number;
            // Sparc is a Big Endian machine
            memcpy ((char *)(&number),buffer,4);
            sign     = number.sign;
            exponent = number.exponent;
            mantissa = number.mantissa;

            if (exponent) {
                value = (1.0 + (double)mantissa / (1 << 23)) *
                    pow (2.0, (long)(exponent) - 127);
            }
            else {
                if (mantissa) {
                    value = (double)mantissa / (1 << 23) *
                        pow (2.0, (long)(-126));
                }
                else {
                    value=0;
                }
            }
            value = (sign == 0) ? value : -value;
#endif USESUN4NATIVEFLOAT
        }
        else {
            cerr << "read failed\n" << flush;
            value=0;
        }

              4.3.1.3 Strings

                      Strings obey the usual C convention of null terminated
strings without a length preamble.

        4.3.2 Operating System

5.  Compression Schemes

    5.1 Reversible
    5.2 Irreversible
        5.2.1 Perimeter Encoding

6.  Getting Connected

    6.1 Tapes

        Nine-track half-inch tapes were the old medium of choice for archiving
and image exchange and many older pieces of equipment will have these.
Unfortunately most people don't have such a drive on their workstation or
personal computer. There are several possibilities:

          - Use another piece of equipment that has a more modern or
           networked or serial-ported host and a nine-track drive, and
           use it to do the extraction. I used to use a networked Signa 4X
           to do this to extract GE 9800 CT tapes.

          - Visit your MIS department, which almost certainly has an archaic
           mainframe with a tape drive. Sometimes tough to get them to read
           formats they aren't expecting though (the hosts not the people
           I mean :) ).

          - Buy a nine-track for your workstation. This may seem a ridiculous
           idea given the price of new 6250 bpi drives are around $5,000, but
           one can often pick up bargain primitive non-6250 or refurbished
           drive that is adequate for the job.

        The Qualstar 1054 is one such drive, that attaches to a SCSI port, and
works with the regular SunOS SCSI tape driver, once a few tables in the kernel
have been updated as follows, and the kernel rebuilt:

{root}% pwd
/usr/kvm/sys/scsi/targets

{root}% diff -c stdef.h.prequalstar stdef.h
*** stdef.h.prequalstar Tue Aug 30 19:32:24 1994
--- stdef.h     Tue Aug 30 19:32:24 1994
***************
*** 43,48 ****
--- 43,49 ----
  #define       ST_TYPE_FUJI            0x21    /* Fujitsu - (not tested) */
  #define       ST_TYPE_KENNEDY         0x22    /* Kennedy */
  #define       ST_TYPE_HP              0x23    /* HP */
+ #define       ST_TYPE_QUALSTAR        0x24    /* Qualstar */
  #define       ST_TYPE_HIC             0x26    /* Generic 1/2" Cartridge */
  #define       ST_TYPE_REEL            0x27    /* Generic 1/2" Reel Tape */

{root}% diff -c st_conf.c.prequalstar st_conf.c
*** st_conf.c.prequalstar       Tue Aug 30 19:32:22 1994
--- st_conf.c   Tue Aug 30 19:32:22 1994
***************
*** 153,158 ****
--- 153,174 ----
   * so our best guess as to their capabilities is
   * included herein.
   */
+ /* Qualstar 1054 or 1260s scsi 9-track with 64KB buffer */
+ {
+       "Qualstar 1054/1260s 1/2\" Reel", 7, "NCR ADP-53", ST_TYPE_QUALSTAR,
10240,+       (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
+       300, 300,
+       { 0x00, 0x02, 0x06, 0x03},
+       {  0, 0, 0, 0 }
+ },
+ /* Qualstar 1054 scsi 9-track with 256KB buffer */
+ {
+       "Qualstar 1054 1/2\" Reel", 10, "QUALSTAR10", ST_TYPE_QUALSTAR, 10240,
+       (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
+       300, 300,
+       { 0x00, 0x02, 0x06, 0x06},
+       {  0, 0, 0, 0 }
+ },
  /* Wangtek QIC-150 1/4" cartridge */ {
        "Wangtek QIC-150", 14, "WANGTEK 5150ES", ST_TYPE_WANGTEK, 512,
        (ST_QIC | ST_AUTODEN_OVERRIDE),

        I got my Qualstar 1054 from Bill Power at Power Computer Services for
only $750 and have successfully read GE 9800 CT and Philips S15 MR tapes with
it so far. See the "Sources" section for where to get one.

        Once you have such a tape connected to the SCSI port, one can either
write simple programs to read files (easiest if the tape has variable length
records) or use shell scripts and the "dd" command with whatever the correct
block size is. See dd(1), mt(1), and mtio(3) for more information. Remember
that the read(2) call reads one fixed or variable length record at a time, and
returns 0 bytes read for a tape mark, and two tape marks in a row indicates the
end of the tape (normally). If you encounter short files with a series of
records 80 bytes long chances are you are dealing with header/end markers. This
is what ANSI standard tapes off VAX VMS seem to look like.

        Anyone who has any further information about tape formats and handling,
especially references to standard or on-line documents please let me know.

    6.2 Ethernet

    6.3 Serial Ports

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.
Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01


7.  Sources of Information

    7.1 Vendor Contacts

       - ANSI - Getting a Registered Organization Number for a DICOM UID Root:

                Registration Coordinator
                Michelle A. Maas
                phone [phone]
                phone [phone]
                fax   [phone]
                e-mail ATTMAIL.COM!MMAAS
                X.400  C=US AD=ATTMAIL G=MICHELLE S=MAAS USER NAME=MMAAS

                numeric identifier costs $1000 and takes 10 days
                organization name  costs $1500 and takes 90 days

       - DICOM and ACR/NEMA standards:

                NEMA Publication Sales
                2101 L St. NW, Suite 300
                Washington DC 20037-1526
                phone [phone]

       - DICOM standards comments and working group information:

                David Snavely, Staff Executive
                NEMA
                2101 L St. NW, Suite 300
                Washington DC 20037-1526
                phone [phone]

                Gordon Bass
                American College of Radiology
                1891 Preston White Drive
                Reston VA 22091
                phone [phone]

       - FDA approval for PACS and Related Devices:

        Guidance for the Comment and Review of 510(k)
        Notifications for PACS and Related Devices

        Small Manufacturers Assistance
        phone [phone]
        fax   [phone] (flash system for document delivery)

       - FDA standards:

        Fedworld Gateway
        modem [phone]
        telnet://fedworld.gov
        ftp://ftp.fedworld.gov
        http://www.fedworld.gov/

       - General Electric, contact for DICOM related stuff:

                Donald E. Van Syckle
                Senior Systems Analyst
                GE Medical Systems
                3200 N. Grandview Blvd.
                Waukesha WI 53188
                phone [phone]
                fax   [phone]
                email [e-mail]

       - General Electric, contact for image format information:

                John Meissner
                Networks Technical Leader
                GE Medical Systems
                N25 W23255 Paul Road
                Pewaukee WI 53072
                phone [phone]
                email [e-mail]

       - General Electric, Ultrasound contact:

                Paul Mullen
                Radiology Product Manager
                email [e-mail]
                email [e-mail] (Paul Mullen)

       - Independent JPEG Group (IJG):

                [e-mail] (Tom Lane)

       - Interfile contacts:

                [e-mail] (Trevor Cradduck)
                [e-mail] (Andrew Todd-Pokropek)

       - Images - digitized mammograms:

                - no FTP site
                - 50 each, normal and cancer mammograms
                - digitized at 200 micrometers and 8 bits
                - provide them with an appropriate tape
                - Contact:

                Maria Kallergi, PhD
                Department of Radiology
                University of South Florida
                12901 Bruce B. Downs Blvd., Box 17
                Tampa, FL   33612-4799
                phone [phone]
                fax   [phone]
                email [e-mail]

    7.2 Relevant FAQ's

       - Archive-name: graphics/resources-list/part[1-3]
       - Archive-name: graphics/faq
       - Archive-name: pixutils-faq
       - Archive-name: image-processing/Macintosh
       - Archive-name: sci-data-formats
       - Archive-name: compression-faq/part[1-3]
       - Archive-name: jpeg-faq
       - Archive-name: medical-image-faq/volume-visualization

       - DICOM FAQ

                  - maintained by [e-mail] (David S. Channin)
                  - periodically posted to comp.protocols.dicom

       - FITS basics and information (periodic posting)

                - FITS (Flexible Image Transport System)
                - for astronomical data
                - periodically posted by
                      [e-mail] (Barry M. Schlesinger)
                - in sci.astro.fits,sci.data.formats

    7.3 Source Code

        See under FTP/WWW Sites

    7.4 Commercial Offerings

       - Anatomical images on CDROM and other atlases:

        A.D.A.M Software, Inc.
        phone (800) 408-ADAM Dept 502
        phone (800) 408-ADAM Dept 504
        phone [phone]

        Lifeart
        phone [phone]
        phone [phone]

        BodyWorks
        Software Marketing Corp
        9830 South 51st St, Bldg. A-131
        Phoenix, AZ  85044
        phone [phone]

        VoxelMan Atlas
        Springer-Verlag, Electronic Media
        175 Fifth Avenue
        New York, NY 10010
        phone  [phone]
        phone  [phone]
        email  [e-mail]

       - Conversion from proprietary formats:

        Phil Femano
        Medical Imaging Consultants
        phone [phone]

       - Conversion from proprietary to ACR/NEMA format (MedVision for Mac):

                Evergreen Technologies
        Jeffrey Siegel
                Main Street, PO Box 795
                Castine  ME 04421
                phone [phone]
                fax   [phone]
        email [e-mail]
        email [e-mail]
        email [e-mail]

       - Data General RDOS & AOS TCP/IP solution:

                Claflin & Clayton
                203 Southwest Cutoff
                Northboro, MA 01532
                phone [phone]
                fax   [phone]
                email [e-mail]
                email [e-mail]

       - Data General themselves:

                DG Direct
                phone [phone]

       - Interfaces between vendors and DICOM 3.0 toolkits:

                DeJarnette Research Systems Inc.
                Suite 700
                401 Washington Avenue
                Towson, Maryland 21204
                USA
                phone [phone]
                fax   [phone]
                email [e-mail]

                Merge Technologies, Inc.
                1126 S. 70th St
                Milwaukee, Wisconsin 53214-3151
                phone [phone]
                fax   [phone]
                email [e-mail] (Dwight Simon)

                Kodak Health Imaging Systems
                18325 Waterview Parkway
                Dallas TX 75252
                phone [phone]
                fax   [phone]
                email [e-mail] (C.B.Stone)

       - InterFormat - qsh to Interfile conversion, ACR/NEMA to qsh, et al.

                - medical image format translation program
                - automatically identifies and translates heterogeneous files
                - Motif interface for user browsing & image selection
                - input formats:

                        - GE 8800 CT, 9800 CT, Advantage CT & MR, Signa MR
                        - Technicare 2000 CT
                        - Positron PET
                        - Philips 300 Series CT
                        - Trionix Triad SPECT
                        - Siemens Somatom CT, Siemens Magnetom MR, CTI PET
                        - Varian CTSIM
                        - ACR-NEMA 1.0, ACR-NEMA 2.0, and AAPM/qsh

                - output formats:

                        - AAPM/qsh
                        - Interfile
                        - ADAC Interfile
                        - Varian CTSIM

                - other formats planned, including DICOM 3

                David Reddy                       <--- USA contact
                Radio Logic, Inc.
                P.O. Box 9665
                New Haven CT 06536
                phone  [phone]
                email  [e-mail]

                Bartec Medical Systems Ltd.       <--- UK, Europe & Mideast
                Impression House
                Invincible Road
                Farnborough Hampshire
                GU14 7NP England
                email  [e-mail]

       - Network hardware for PACS/telemedicine/WAN.

        John A Hansen
        Networks Northwest Inc.
        PO Box 40209
        Bellevue Wa 98015
        phone  [phone]
        phone  [phone]
        fax    [phone]
        email  [e-mail]

       - Plug-ins for Adobe Photoshop and NIH Image.


        - ImportACCESS

        A commercial Photoshop plugin that works with the many other
                programs that support the plugin format. Reads fixed format
                proprietary formats, and extra modules for ACR-NEMA 2.0,
                DICOM 3.0, Interfile 3.3 files are available. Particularly
                good at multi-slice images and color images, and clearly has
                a nuclear medicine bias to it. Well documented. Recommended.
                Note of potential bias - I was a beta tester.

        Hugh Lyshkow
        Designed Access
        702 Wrightwood Ave.
        Chicago IL 60614
        phone  [phone]
        fax    [phone]
        email  [e-mail] (Hugh Lyshkow)


       - Scanners for Xray films.

        Nathan Harris
        DBA Systems, Inc.
        phone  [phone]
        email  [e-mail]

        Lumisys

        Cobrascan

        Vidar

        XRS
        email [e-mail]

       - Tape drives - 9-track 1/2".

        Power Computer Services           <--- $750 Qualstar 1054 SCSI
        1132 Olympic Drive
        Corona CA 91719
        phone [phone]
        phone [phone]
        fax   [phone]
        email [e-mail] (Bill Power)

        Bill is also working on an 9-track interface replacement
        to record on removable hard disk cartridges, to upgrade
        old equipment.

       - Teleradiology equipment vendors.

        CompuMed Inc
        Cary Cole
        1200 No El Dorado Pl
        Suite C300
        Tucson AZ 85715
        phone [phone]
        fax   [phone]
        email [e-mail]

       - Video capture from medical devices.

        Precision Digital Images
        Lewis C. Larson
        6742 - 185th Ave. NE
        Suite 100
        Redmond, WA  98052
        phone [phone]
        fax   [phone]
        email [e-mail] (Lewis C. Larson)

       - Viewers for Mac and/or Windows:

                Evergreen Technologies
        Jeffrey Siegel
                Main Street, PO Box 795
                Castine  ME 04421
                phone [phone]
                fax   [phone]
        email [e-mail]
        email [e-mail]
        email [e-mail]

        MultiView for Macintosh
        Image Data Corp.
        Don Alvarez
        11550 IH-10 West
        San Antonio, TX 78230-1024
        phone [phone]
        fax   [phone]

        Alice
        Hayden Image Processing Group
        Boulder, Colorado, USA
        phone [phone]
        fax   [phone]
        email [e-mail]

        Imaging Solutions
        phone [phone]
        email [e-mail] (Marc Dinkes)

        SiteView (Windows and SunOS 4.x)
        Joe Shapiro
        phone [phone]
        fax   [phone]
        email [e-mail]
        email [e-mail]
                demo ftp://wuarchive.wustl.edu/graphics/graphics/demo-packages/
                demo ftp://ftp.cica.indiana.edu/pub/pc/win3/demo/

       - Visible Human on CDROM.

        Research Systems, Inc
        email [e-mail]
        email [e-mail] (Peter Hallett)

    7.5 FTP/WWW sites

       - 3D Reconstruction:

                - http://biocomp.arc.nasa.gov/3dreconstruction

       - 3DVIEWNIX (University of Pennsylvania):

        NB. The new 1.1 version has a different distribution policy
        and complete binary software, rather than just a demo, is
        available from the ftp site.

                - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/BINARIES
                - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MPEG_MOVIES
                - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/DATA
                - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/PAPERS
                - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/MANUALS
                - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/SRC
                - ftp://mipgsun.mipg.upenn.edu/3DVIEWNIX1.1/TUTORIALS
                - http://mipgsun.mipg.upenn.edu

       - ACR Index of Radiologic Diagnoses (ascii text files):

                - ftp://ftp.xray.hmc.psu.edu/acr_codes
                - http://www.xray.hmc.psu.edu/

       - ACR/NEMA plugins for Adobe Photoshop (works with NIH Image also):

                - ftp://sumex-aim.stanford.edu/info-mac

                    - /Graphic/Utility/photoshop-acr-nema.hqx

                - ftp://zippy.nimh.nih.gov/pub/nih-image

            - /plug-ins/ACRNema.hqx
            - /user-macros/import_ACR_NEMA.txt


       - Anatomy - interactive programs:

                - ftp://ftp.monash.edu.au/pub/medical

       - Anatomy - lung:

                - http://indy.radiology.uiowa.edu
                         /rad/books/LungAnat/LungAnat.html

       - Angiography simulation:

                - ftp://ftp.comp.vuw.ac.nz/pub/graphics/peter/xras-1.0.tar.gz
                - http://www.comp.vuw.ac.nz/~peter/

       - Blood flow modelling:

                - [e-mail] (George Foutrakis)
                - http://www.neuronet.pitt.edu:8910/~georgef
                - http://www.pitt.edu/~gnfst1

       - CT reconstruction software:

                - ftp://peipa.essex.ac.uk/ipa/src/process

                        - ct.tar.Z
                        - snark77.tar.Z

       - Clip Art of things medical:

                - http://www.mindspring.com/~mperloe/gallery.html
                - ftp://goofy.cs.umd.edu/f/clipart/medical

       - Dermatology:

                - http://www.rrze.uni-erlangen.de/

                    - /docs/FAU/fakultaet/med/kli/derma/

       - DICOM conformance statements:

                -  General Electric.
            ftp://ftp.med.ge.com/pub/dicom

                -  Index.
            http://www.xray.hmc.psu.edu/

       - DICOM conversion tools (from proprietary formats) and utilities:

                - dicom3tools_*.tar.gz

            - ftp://ftp.rahul.net/pub/dclunie
                    - http://www.rahul.net/dclunie


       - DICOM data dictionary:

                - From NIH ftp://zippy.nimh.nih.gov/pub/nih-image

            - /documents/dicom-dict.txt

                - In dicom3tools_*.tar.gz

            - ftp://ftp.rahul.net/pub/dclunie
                    - http://www.rahul.net/dclunie


       - DICOM draft standards:

               - ftp://ftp.xray.hmc.psu.edu/dicom_docs
               - ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_docs

        - DICOM RSNA demonstration software:

                 Contact [e-mail] (Steve Moore)

                - ftp://wuerlim.wustl.edu/pub/dicom

                - ftp://ftp.xray.hmc.psu.edu/dicom_software

                        - /Mallinckrodt
                         Mallinkrodt RSNA
                        - /European
                         European CEN/TC251/WG4

                - ftp://ftp.uni-oldenburg.de/pub/dicom/dicom_software

                - Linux port of Mallinckrodt CTN software

                        - From ftp://ss10.numed.szote.u-szeged.hu/pub/MIR-CTN/

                            - Modified sources /Linux/CTN.Linux.tar.Z
                            - Compiled binaries /Linux/CTN.Linux.bin.tar.Z

                        - Ported by [e-mail]

        - DICOM sample images:

               - ftp://wuerlim.wustl.edu/pub/dicom/images/version3

               - In the Mallinckrodt software, there are a few sample
        images ... look in:

                       - apps/simple_storage/D19051502.9
                       - apps/simple_storage/D19051513.9
                        (contain images, but are ACR/NEMA 2 and missing lots
                        of required type 1 and 2 attributes)

        same in:

                       - apps/send_image
                       - apps/move_image

        also:

                       - apps/displays/TEST_IMAGES/baby.color.img
                        (contains image, but is not legal DICOM 3 (no UID's))
                       - apps/displays/TEST_IMAGES/ct1.1
                        (valid DICOM 3 CT IOD (passes Mallinckrodt dcm_verify))

                - ftp://ftp.med.ge.com/pub/dicom
                - http://www.xray.hmc.psu.edu/public/med_img_dbs.html

       - Dr. Razz - image viewer for MAC:

                - ftp://ftp.u.washington.edu/pub/user-supported/razz
                - ftp://ftp.u.washington.edu/public/razz
                - http://www.rad.washington.edu/

        The author (Thurman Gillespy [e-mail]) writes:

        Dr Razz is a 16 bit medical image display and analysis
        program for Macintosh computers. Dr Razz can window and
        level on full 16 bit image data in near real time on any
        Macintosh color computer. Images can be viewed individually,
        or an image series can be viewed in an image stack. The
        program attempts to automatically open CT and MRI images,
        and can usually handle different header sizes and byte order.
        The program can directly read the headers of images created
        with the GE Image Extract Tool, and can automatically handle
        compressed images created with this utility. Dr Razz is not a
        DICOM viewer, although it can probably automatically open many
        CT/MRI DICOM images if they are not compressed. An option for
        manually entering image parameters for problem files is
        available. Images can be saved as PICT files, and TIFF support
        will be added.

       - FITS (Flexible Image Transport System) for astronomical data:

                - ftp://fits.cv.nrao.edu/fits
                - ftp://nssdca.gsfc.nasa.gov/FITS

       - Graphics file formats (gif,tiff,etc.)

                - ftp://zamenhof.cs.rice.edu/pub/graphics.formats

       - Hierarchical Database Management System (astronomy images):

                - ftp://starlink-ftp.rl.ac.uk/pub/doc/star-docs/sun92.tex
                - http://star-www.rl.ac.uk/

       - Interfile sources -  see Nucmed ftp site at UWO.

       - JPEG Sources

               - PVRG-JPEG CODEC:

                ftp://havefun.stanford.edu/pub/jpeg

                        Supports

                          - sequential DCT baseline,
                          - lossless modes.

                - IJG:

                 ftp.uu.net/graphics/jpeg

                        Supports

                          - sequential DCT baseline,
                          - 12 bit DCT modes.

       - Kermit distribution:

                - ftp://ftp.cc.columbia.edu/kermit

       - LUNIS - Loyola University Nuclear Medicine Information System

                - http://147.126.104.3/

                contact [e-mail] (Jim Halama) for
        access, which is restricted ([phone])

       - Medical imaging research (University of Leeds):

                - http://agora.leeds.ac.uk/comir/comir.html

       - Medical Informatics standards, including HL7:

                - ftp://dumccss.mc.duke.edu/standards

                        - read-me.txt
                        - HL7/pubs/version2.2/ballot1.zip

       - Neuroscience Resources List:

                - http://golgi.harvard.edu/biopages/neuro.html

       - NIH Image - Macintosh image processing software:

                - ftp://zippy.nimh.nih.gov/pub/nih-image

       - PACS - EurIPACS:

                - http://www.rad.unipi.it:7080/

                    - /works/imphone/presentation-imphone.html

       - Papyrus and Osiris ftp site:

                - ftp://expasy.hcuge.ch/pub/Osiris

            - Papyrus specifications for versions 2.1 and 3.
            - Osiris for Mac, PC and Unix (SunOS, Solaris, Dec).
            - Sample images for Dicom, Papyrus 2 and Papyrus 2.

                - http://expasy.hcuge.ch/www/UIN/UIN.html

       - Nucmed ftp site at UWO (run by Trevor Cradduck ([e-mail])):

                - ftp://uwovax.uwo.ca/PUB:[000000.NUCMED]

       - Penn State Radiology Web Server:

                - http://www.xray.hmc.psu.edu/

       - PET:

                - http://www-ipg.umds.ac.uk/pet/petcen.html

       - Physics:

                - http://www.physics.mcgill.ca/physics-services/
                - http://tph.tuwien.ac.at/physics-services/

       - Qsh by ftp:

                - ftp://nucmed.med.nyu.edu/pub

                        - /dist
                                 compressed tar
                        - /qsh
                                 source

       - Radiological Society of North America - On-Line Sources:

                - http://www.rsna.org
                - http://www.rsna.org/edu/internet.html

       - Radiology History:

                - http://www.fh-wuerzburg.de/roentgen/

       - Sample mammogram images:

                - [e-mail] (J.Suckling) (Normal and abnormal)

                - ftp://ftp.xray.hmc.psu.edu/mammo (10 Normal)
                - http://www.xray.hmc.psu.edu/

       - Sample medical images (may be out of date):

                - ftp://fokus.uke.uni-hamburg.de/.voxelman.images
                - ftp://rwja.umdnj.edu/pub
                - gopher://gopher.austin.unimelb.edu.au/11/images/petimages/
                - ftp.nihon-u.ac.jp/pub/data/MRIMonkeyHead
                - http://ftp.nc.nihon-u.ac.jp/pub/data/MRIMonkeyHead
                - ftp://decaf.stanford.edu/pub/images/medical/mri
                - ftp://eedsp.gatech.edu/database/images/wchung/medical
                - ftp://omicron.cs.unc.edu/pub/softlab/CHVRTD
                - http://foyt.indyrad.iupui.edu/medres/iurad2.html
                - ftp://ccsun.unicamp.br
                - ftp://boris.umds.ac.uk/pub/images
                - http://www-ipg.umds.ac.uk/

       - University of Washington Teaching File ([e-mail]):

                - http://www.rad.washington.edu/

                1.  Radiology Teaching File (CME credit)
                2.  Anatomy Teaching Modules
                3.  Radiology Exhibits from UW
                4.  Information on UW radiology residency/fellowship programs
                5.  Image processing software written by UW faculty

       - University of Western Ontario Teaching File:

                - http://johns.largnet.uwo.ca

       - Vax help - "The Vax Book" by Joseph E St Sauver, U of Oregon:

                - ftp://decoy.uoregon.edu

       - Visible Human Project

                - http://www.nlm.nih.gov/

                    - /factsheets.dir/visible_human.html
                    - /extramural_research.dir/visible_gallery.html

        Dr. Michael J. Ackerman
        Project Officer, Visible Human Project
        National Library of Medicine
        8600 Rockville Pike
        Bethesda, MD 20894

        Need to sign an agreement with the NLM before one can
        transfer the 15 GB of data or buy tapes.

        Tape can be purchased from NTIS [phone] in Unix
        tar format for $1000.

       - Wavelet compression software:

                - ftp://pascal.math.yale.edu/pub/wavelets
                - ftp://pascal.math.yale.edu/pub/software

       - Window level software (12/16 bits ->8):

                - ftp://alvin.ach.uams.edu/pub/winlev.tar.Z (Includes images)
                - ftp://alvin.ach.uams.edu/pub/winlev-noimages.tar.gz

       - Wxwin software:

                - ftp://skye.aiai.ed.ac.uk/pub/wxwin

       - Xsee - X-windows based display program for raw images:

                - available from [e-mail] (Stefan Thurnhofer)

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.
Archive-name: medical-image-faq/part2
Posting-Frequency: monthly
Last-modified: Sat Feb 18 16:42:58 GMT+0300 1995
Version: 2.01


    7.6 Mailservers

       - Ftpmail:

                Ftpmail is a service provided by some extremely generous
                sites that allow you to send ftp commands to them by email
                and the server executes the commands and sends the results
                back. Very few sites offer this because of the huge load
                and potential for abuse. I only mention it here because a
                lot of medical imaging people don't seem to have anonymous
                ftp access.

                To find out more, fetch the relevant FAQ from the mailserver
                at "[e-mail]" with a message body:

                        send usenet/news.answers/ftp-list/faq

                The most commonly used site is "[e-mail]" (send
                "help" (no quotes) in the message body).

       - HSPNET-L Hospital Computer Network Discussion Group and Data Base:

        Run by Don Parsons [e-mail].

        - To subscribe:

            To: [e-mail]
            Subject:
            SUBSCRIBE HSPNET-L your_full_name

        - For the monthly digest:

            To: [e-mail]
            Subject:
            AFD ADD HSP* DIGEST HSPNET-L

        - To contribute (if subscribed):

            To: [e-mail]

        - To download from the LISTSERV Database:

            To: [e-mail]
            Subject:
            INDEX HSPNET-L
            GET <filename> <filetype>

        HSPNET-L is mirrored by "sci.med.telemedicine" Usenet newsgroup.

       - Interfile mailing list:

                Don't know much about this list, but I am sure that
                [e-mail] (Andrew Todd-Pokropek) would
                be able to fill you in on this.

       - Medimagex list for medical image format discussions:

                Precursor to "alt.image.medical" usenet news group. Now
                essentially defunct. Maybe useful if you don't have
                Usenet News access.

        - command address:   [e-mail]
                - commands:          in message body not subject
                - list name:         MEDIMAGEX
                - to get help:       HELP and/or HELP LISTSERV
                - to subscribe:      SUBSCRIBE MEDIMAGEX firstname lastname
                                    (NB. not your email address, that is
                                     derived from the 'From ' header line)
                - to unsubscribe:    UNSUBSCRIBE MEDIMAGEX
                - to send to list:   [e-mail]

       - Nucmed mailing list for medical physicists:

                - to subscribe:          [e-mail]
                - to unsubscribe, etc.:  [e-mail]
                - to send to list:       [e-mail]
                - the relevant human:    [e-mail] (Trevor Cradduck)

                This list is not actually gated to "sci.med.physics",
        though Trevor often reposts significant items.

                See also Nucmed ftp site at UWO.

       - Radiation Safety Distribution list:

        For Health Physicists, Medical Physicists, Radiological
        Engineers and others who have a professional interest in
        matters related to Radiation Protection.

        [e-mail]

       - Radiologic Science Discussion Group - Radsci-L:

         Discussion may choose to center around radiologic science
         education, medical radiography, CT (computerized scanning),
         MRI (magnetic resonance scanning), sonography, nuclear
         medicine, radiation oncology, veterinary medicine, industrial
         applications, radiologic patient care, etc.

        - command address:   [e-mail]
                - commands:          in message body not subject
                - list name:         Radsci-L
                - to subscribe:      subscribe Radsci-L firstname lastname
                                    (NB. not your email address, that is
                                     derived from the 'From ' header line)

       - sci.med.radiology gateway:

        [e-mail]

    7.7 References

       - DICOM - Directory of Resources:

                "DICOM Tools for End User Applications
                and System Integration"
                Presented at EuroPACS'94 Geneva Switzerland
                Dwight Simon

                Merge Technologies, Inc.
                1126 S. 70th St. Suite N508B
                Milwaukee, Wisconsin 53214-3151
                phone [phone]
                fax   [phone]
                email [e-mail] (Dwight Simon)

       - DICOM - General:

                Kodak "Understanding DICOM 3.0" for $US 12.50 (no credit cards)

                Angie Helms
                Kodak Health Imaging Systems
                18325 Waterview Parkway
                Dallas TX 75252
                phone [phone]

       - DICOM - Implementation:

                "Implementation of the DICOM 3.0 Standard
                    - A Pragmatic Handbook"
                Robert Hindel, Editor

        RH Consulting
                483 Ridge Road
                Orange CT 06477-2830
                phone [phone]
                fax   [phone]
                email [e-mail] (Robert Hindel)

        Radiological Society of North America
                2021 Spring Road Suite 600
                Oak Brook IL 60521

       - PACS:

                Understanding PACS:Picture Archiving & Communications Systems

                available for $5 from:

                        SCAR, Society for Computer Applications in Radiology
                        4750 Lindle Road,
                        P.O. Box 8800
                        Harrisburg, PA 17105-8800
                        phone [phone]

       - Telemedicine:

                Rural TeleHealth:Telemedicine,Distance Education &
                Informatics for Rural Health Care, A Report of the Office
                of Rural Health Policy Health Resources and Services
                Administration, DHSS (Nov,1993)

                available for $8 from:

                        WICHE Publications
                        Western Interstate Commission for Higher Education
                        P.O. Drawer P
                        Boulder, CO  80301-9752
                        phone [phone]
                        fax   [phone]

       - Wavelet compression:

                Press, et al. Numerical Recipes in C.
                Chapter 13.10. Wavelet Transforms.

                Cody,MA. The Wavelet Packet Transform.
                Dr. Dobb's Journal, April '94

    7.8 Organizations and Societies

       - IEEE Transactions on Medical Imaging

        Mike Vannier
        Mallinckrodt Institute of Radiology
        Washington University Medical Center
        510 South Kingshighway Blvd.
        St. Louis, MO 63110

       - Society for Computer Applications in Radiology

        4750 Lindle Road,
        P.O. Box 8800
        Harrisburg, PA 17105-8800
        phone [phone]
        email [e-mail]
        email [e-mail] (Thurman Gillespy).

               - Web server is at http://www.scar.rad.washington.edu/

               - Official journal is the "Journal of Digital Imaging".

               - Last meeting was S/CAR'94 held in Winston-Salem,
                North Carolina during June 1994.

               - (membership is considered mandatory for FAQ readers :) )

    7.9 Usenet Newsgroups

       - alt.graphics.pixutils
       - alt.image.medical
       - alt.med.equipment
       - comp.graphics
       - comp.graphics.algorithms
       - comp.graphics.pixutils
       - comp.graphics.research
       - comp.protocols.dicom
       - sci.data.formats
       - sci.med.emergency
       - sci.med.informatics
       - sci.med.physics
       - sci.med.radiology
       - sci.med.telemedicine
       - sci.med.vision

8.  Acknowledgements

    Thanks to the following people for contributions, general help, interesting
postings or mail whose contents have found there way in here, or just plain old
moral support. If I have inadvertently omitted anyone, sorry !

               -                     <[e-mail]>
               -                     <[e-mail]>
               - Aaron Davis         <[e-mail]>
               - Alan Rowberg        <[e-mail]>
               - Allen Rueter        <[e-mail]>
               - Alvis D. Harding Jr <[e-mail]>
               - Andreas Bittorf <[e-mail]>
               - Andreas Pommert     <[e-mail]>
               - Andrei Cornoiu      <[e-mail]>
               - Andrew ToddPokropek <[e-mail]>
               - Andy Hewett         <[e-mail]>
               - Bob Dempsey         <[e-mail]>
               - Bob Manich          <[e-mail]>
               - Botond K. Szabo     <[e-mail]>
               - Bud Wendt           <[e-mail]>
               - C.B.Stone           <[e-mail]>
               - CC Yau              <[e-mail]>
               - Charles Bird        <[e-mail]>
               - Christoph Ozdoba    <[e-mail]>
               - Chuck Batishko      <[e-mail]>
               - Craig D. von Land   <[e-mail]>
               - David P Reddy       <[e-mail]>
               - David S. Channin    <[e-mail]>
               - Derek Hill          <[e-mail]>
               - Dick St.Peters      <[e-mail]>
               - Dick St.Peters      <[e-mail]>
               - Don Parsons         <[e-mail]>
               - Donald Van Syckle   <[e-mail]>
               - Dwight Simon        <[e-mail]>
               - Edward Gosfield     <[e-mail]>
               - Eric John Finegan   <[e-mail]>
               - Fred W. Prior       <[e-mail]>
               - George Foutrakis    <[e-mail]>
               - Gerald Q. Maguire   <[e-mail]>
               - Gerrit Visser       <[e-mail]>
               - Greg Gibbs          <[e-mail]>
               - Guillaume Thelissen <[e-mail]>
               - Gunther Nowotny     <[e-mail]>
               - Herve Delingette    <[e-mail]>
               - Hugh Lyshkow        <[e-mail]>
               - Irene Gearin        <[e-mail]>
               - James Harrison      <[e-mail]>
               - Jeff Paynowski      <[e-mail]>
               - Jeff Wade           <[e-mail]>
               - Jeffrey Siegel      <[e-mail]>
               - Jerry McCarthy      <[e-mail]>
               - Jim Berilla         <[e-mail]>
               - Jim Swan            <[e-mail]>
               - Joe Shapiro         <[e-mail]>
               - Joel Davis          <[e-mail]>
               - John A. Hansen      <[e-mail]>
               - John Clayton        <[e-mail]>
               - John Hearns         <[e-mail]>
               - John L. Groezinger  <[e-mail]>
               - John Meissner       <[e-mail]>
               - K Schulze           <[e-mail]>
               - Keith Robison       <[e-mail]>
               - Kevin Montgomery    <[e-mail]>
               - Krishna Iyer        <[e-mail]>
               - Lasse Jyrkinen      <[e-mail]>
               - Marilyn E Noz       <[e-mail]>
               - Mark Dinkes         <[e-mail]>
               - Mark Perloe         <[e-mail]>
               - Martin Liversage    <[e-mail]>
               - Matthew T. Adams    <[e-mail]>
               - Matti Haveri        <[e-mail]>
               - Michael P. McIntyre <[e-mail]>
               - Michael Richardson  <[e-mail]>
               - Nathan A. Harris    <[e-mail]>
               - Neil Weisenfeld     <[e-mail]>
               - Nick Efford         <[e-mail]>
               - Pat Wallace         <[e-mail]>
               - Paul Malloy         <[e-mail]>
               - Paul Mullen         <[e-mail]>
               - Peter Hall          <[e-mail]>
               - Peter Hallett       <[e-mail]>
               - Peter Jurgensen     <[e-mail]>
               - Peter Neelin        <[e-mail]>
               - Phil Pillet         <[e-mail]>
               - Phillip Berman      <[e-mail]>
               - R. Krishnamurthy    <[e-mail]>
               - Rafael Pous         <[e-mail]>
               - Rex Harmon          <[e-mail]>
               - Richard R Carlton   <[e-mail]>
               - Robert Hindel       <[e-mail]>
               - Roch Comeau         <[e-mail]>
               - Rutie Adar          <[e-mail]>
               - Scott M Metzger     <[e-mail]>
               - Shigeru Muraki      <[e-mail]>
               - Steve Moore         <[e-mail]>
               - Thurman Gillespy    <[e-mail]>
               - Tom Lane            <[e-mail]>
               - Tracy N. Tipping    <[e-mail]>
               - Trevor Cradduck     <[e-mail]>
               - Tunc Iyriboz        <[e-mail]>
               - Varun Mitroo        <[e-mail]>
               - Wayne Rasband       <[e-mail]>
               - Yuichi Kimura       <[e-mail]>

--
David A. Clunie ([e-mail])
In sunny Riyadh, Saudi Arabia.